I have two isdn-30 lines with call manager & one voice gateway 3725 router (1mfte1 & 2mfte1 e1 interfaces). They are currently supporting one did block 6828710 to 6828-7699. I am installing second new did block 6829 - 3000 to 6829-3199. PTT have make arrangement on new did block will be coming at the last 10 channels to the second isdn line. Can Cisco IOS controls/sets ISDN signal coming from the first 20 lines is for existing did block 68287xxx and last 10 lines is for new did block 6829xxx
below is my current voice pot definition
dial-peer voice 2003 voip
description INCOMING CALLS FROM E1 TO CALLMANAGER 68293?
progress_ind setup enable 3
translate-outgoing called 2
voice-class h323 1
session target ipv4:172.30.160.11
fax rate disable
fax protocol cisco
comments from PTT
The reason you are seeing 6828 7333 is because the call is going through
tp1.01 jpg1348 uam1-01 or it is going through the first 20 channels of
tp1.02 jpg1348 uam1-01. If you configure the calls to go through the
last 10 channels of tp1.02 jpg1348 uam1-01 then it will show you the
As for the incoming call you should also configure to receive call from
the last 10 channels of tp1.02 jpg1348 uam1-01.
The switch will decide on which channel to send the incoming call, and the router will give the call to the CM no matter the channel used. Since the blocks do not overlap, there is no problem anyway.
I do not quite understand why your telco got so worried in making sure that one DID block is sent into one line/set and the other into another. E.G. what happens after the 'last 10 channels' of that circuit are taken, and the 11th call comes in ??
I did not indicated my problem.
For outgoing call, isdn trace tells me the call is from new did block ie. 6829 3133. However, the called party displays the prime number 6829 7333 as the caller.
For incoming call, isdn trace tells me the call is going to 6829 3133 but the 3133 extension did not ring. PTT explained they allocated the last 10 pri lines to new block. If the voice traffic takes/comes in using the first 20 lines, called party will show prime number as well as no incoming call.
For outgoing calls, the router strictly uses the first available channel in either ascending or descending order, depending on how is configured. It is not supported to have 'channel sets' and select an arbitrary channel for outgoing calls, at least with H.323. Perhaps that would be possible with MGCP, but I doubt. I'm surprised to know that telco has provisioned the line based on the assumption that your equipment will use a specific channel depending on DID.
For incoming calls, I cannot tell you why the phone doesn't ring. Once the call comes in, and you said it does, it only depends on your dial-peer and CM configuration to route appropriately, so may you need to do a little more debug.
I will review the Cisco design with ptt and will ask what solution/suggestion he can offer to me. my bottom line is to mizemize the in-house Cisco equipment and avoid increasing additional recurring cost on adding new isdn-pri line.
from what I've seen in my experience, telco should provision both PRI's in hunt group, so that for outgoing calls, as long the calling number falls within your DID blocks, it will be passed to the called party. Any other number will be replaced with the pilot number. You can always configure the CM so that certain extensions will present the main number and not their DID.
For incoming, you should be able to accept any number on any PRI.
This setup has the advantage that in the event one PRI goes out ot service, the functionality is unchanged, albeit with a reduced number of channels.
Of course, if your call volume does not require two PRIs, you should ask to have one only.
I filed my debug isdn q931 for incoming call to new did block 68293133 from 68287433(my extension) & dial peers in the router. the error showed
Jan 17 14:21:52.161 SG: ISDN Se1/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x9DAE
Cause i = 0x829C - Invalid number format (incomplete number)
Progress Ind i = 0x8288 - In-band info or appropriate now available
Jan 17 14:21:52.165 SG: ISDN Se1/0:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x9A32
I hope it can help why the call did not go to call mgr and ring the phone. May be my new dial peer is wrong. Your guidance.
I had a little trouble reading your debug because is truncated.
However, seems that the router is sending the disconnect on the incoming call. We would need to see the output from debug cch323 (either all or session) to see if the call is going to the CM, and with which numbers. I'm not familiar with the CM but at least can tell if the problem is there, or not.
The CM is disconnecting the call:
*** HERE IS CALLED NUMBER, IT HAS NOT BEEN TRANSLATED
Jan 18 08:03:17.544 SG: generic_send_setup:raw message is 219 bytes:04 03 80 90 A3 18 03 A9 83 9A 6C 0A 01 81 36 38 32 38 37 34 33 33 70 09 C1 36 38 32 39 33 31 33 33 A1 1C B7 9E 01 00 03 67 74 64 00 00 00 AC 49 41 4D 2C 0D 0A 50 52 4E 2C 69 73 64 6E 2A 2C 2C 4E 45 54 35 2A 2C 0D 0A 55 53 49 2C 72 61 74 65 2C 63 2C 73 2C 63 2C 31 0D 0A 55 53 49 2C 6C 61 79 31 2C 61 6C 61 77 0D 0A 54 4D 52 2C 30 30 0D 0A 43 50 4E 2C 30 32 2C 2C 31 2C 36 38 32 39 33 31 33 33 0D 0A 43 47 4E 2C 30 30 2C 2C 31 2C 79 2C 32 2C 36 38 32 38 37 34 33 33 0D 0A 43 50 43 2C 30 39 0D 0A 46 43 49 2C 2C 2C 2C 2C 2C 2C 79 2C 0D 0A 47 43 49 2C 32 32 34 63 36 63 36 38 61 35 62 65 31 31 64 62 62 65 35 64 39 33 31 32 39 39 62 64 36 34 66 31 0D 0A 0D 0A
*** GW and CM ADDRESSES
Jan 18 08:03:17.544 SG: src address = 172.30.160.30 of h225SetupRequest
Jan 18 08:03:17.544 SG: dest address = 172.30.160.12 of h225SetupRequest
Jan 18 08:03:17.544 SG: H.225 SM: changing from H225_IDLE state to H225_REQ_FS_SETUP state for callID A1338
Jan 18 08:03:17.544 SG: cch323_ct_main: SOCK 13 Event 0x1
Jan 18 08:03:17.556 SG: cch323_ct_main: SOCK 13 Event 0x1
Jan 18 08:03:17.556 SG: towner_data=0x63703818, len=45, msgPtr=0x6439F158
cch323_gw_process_read_socket: received msg for H.225
*** CM DISCONNECTS WITH CAUSE 1 (INVALID NUMBER)
Jan 18 08:03:17.556 SG: cch323_h225_receiver: received msg of type RELEASEIND_CHOSEN
Jan 18 08:03:17.556 SG: release_ind: disconnect cause 1 location code 0
Jan 18 08:03:17.556 SG: h323_set_release_source_for_peer: ownCallId, src
If you absolutely need to translate the called number before passing to the CM (but I think that is not necessary) please use the voice translation-profile. Else just configure the CM appropriately (I can't help in this)
You can see statistics of succesful/failed calls on the router, with
show h323 gateway [cause-code stats]
I will escalate my problem to PTT and Cisco TAC. I will post the solution after I fix the problem. Tks your effort.