We have a call manager and about 270 users running for about 1 month now, however we have a problem with dialing certain numbers. All routes are in place on the call manager and the gateway is configured correctly. We can dial 1026 (South African time enquiry), however when dialling 1023 / 1024 the call just rings until it times out. Because the 1026 is working, I know my routing and gateway config is correct, but cannot figure out why or where these 1023 / 1024 numbers are going as when calling them, an IVR should answer the call on the other side. So either the call is getting to where it is meant to be going, or somehow it is sending a "false" ringing indicator to the phone I am calling from.
Has anyone heard or experienced this problem or have any ideas? The call manager is sending the cisco gateway the right digits and according to debugs the call should be going where it is meant to.
Can you tell us what the 1023 & 1024 extensions represent? You mentioned that an IVR should answer. What type of IVR are we talking about? Is it IPCC and if so, are these CTI Route Points that are tied to a script in IPCC?
Let me explain it better (my apologies), in South Africa our main fixed line telecommunications provider is Telkom, they provide a directory enquiries service (1023), and 1026 (Time). You can dial these numbers from any Telkom phone free of charge and their IVR or whatever they are using should answer the call. We have a PRI connected to Telkom on a Cisco 2800 gateway, with SIP Trunks to our CCM 5.1.
I have created routes in the route list 0102X and 01xxx . I can dial 01026 and get through, but when I dial 01023 (Which should use the same route as 1026) the call just rings and rings with no answer. I have thought about it being a codec/signalling problem but we have set up the same service on a VCX using the same codecs and protocols and it works fine. I'm also having the same problem with dialing certain international numbers.
can you activate the debug isdn q931 command while you are making the call to 01023, post the results here. Another thing to check would be to use DNA (https://CCM/dna) and see which CSS/TP the CCM is using to route your Call, verify this again on your CCM traces.
are u using MGCP or H323? if possible post the config of your Gateway.
I have used DNA, and it uses the 0102X as primary match and next closest is 01XXX. So it is going to the gateway fine and sending the right digits. I have attached my gateway config below, note I am only using the first 2 dial peers as the rest were configured for least cost routing to premicells but they havent arrived or been connected up yet.
Your Config seems fine to me. Try adding the following command under the Post dial peer:
progress_ind alert enable 8
Also post the debug isdn q931.
Thanks! I will try it tomorrow when I am on site again, doing debugs during office hours is going to be hectic, too many active calls. I will debug and post results. What exactly does that command you gave me do?
Below is the output of the 1023 in question:
Which dial peer should I put that command under and what does it do?
*May 7 07:34:25.285: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Calling num 7231
*May 7 07:34:25.285: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Called num 1023
*May 7 07:34:25.285: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x149B
Bearer Capability i = 0x8090A3
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9839E
Exclusive, Channel 30
Calling Party Number i = 0x0181, '7231'
Called Party Number i = 0x81, '1023'
*May 7 07:35:10.501: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x149B
Cause i = 0x8090 - Normal call clearing
*May 7 07:35:10.553: ISDN Se0/0/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x949B
*May 7 07:35:10.557: ISDN Se0/0/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x149B
I have found what I think is the problem:
The called party does not send a connect message back to the gateway, the gateway in turn cannot send a connect_ack message back and therefor the call just times out of the timeout period expires, ie: it just rings.
It says I must check the D channels on the ISDn but when doing this there is only active b channels. So now I know what the problem is but have no idea on how to fix it.