ISDN - Calls to certain numbers ring, but never finish connecting.

[voip7372]

Hi

Somehow this ended up in the wrong area of the forums, so I'm reposting it again here (where it should be, so the right people see it)...

We have a site in Japan using ISDN PRI (T1) - 4000 series router.  Most outgoing calls work just fine, but we discovered a few toll free numbers that just ring and never answer.  The local users say they can call these numbers from their mobile phone and it works (some kind of recording should be there after it answers.  

I did a few ISDN Q931 debugs to toll free numbers that work fine and to the numbers that don't work.  You can see the differences below.  For the number that just rings and never answers, it looks like we don't get an 'alerting' message and of course no 'connect' message.

Have you ever seen this before (either in Japan or elsewhere with ISDN PRI)?

Working number 0120912738. Notice the ALERTING and CONNECT messages in this example. I do not see that in the bad call. 
The PSTN sends the alerting and connect message to our Cisco, then Cisco acknowledges the connect message with a CONNECT_ACK message.
Sep 21 08:44:05.237: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-type 0x11 is 0x0 0x0, Calling num 035551212
Sep 21 08:44:05.237: ISDN Se0/1/0:23 Q931: Sending SETUP callref = 0x03B1 callID = 0x8332 switch = primary-ntt interface = User
Sep 21 08:44:05.237: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref = 0x03B1
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Calling Party Number i = 0x0080, '0355551212'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '0120912738'
Plan:Unknown, Type:Unknown

Sep 21 08:44:05.384: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8 callref = 0x83B1
Cause i = 0x82E46C - Invalid information element contents
Call State i = 0x01
Sep 21 08:44:05.386: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x83B1
Channel ID i = 0xA98381
Exclusive, Channel 1
Sep 21 08:44:06.312: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x83B1
Progress Ind i = 0x8488 - In-band info or appropriate now available
Sep 21 08:44:07.161: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x83B1
Progress Ind i = 0x8488 - In-band info or appropriate now available
Sep 21 08:44:07.242: ISDN Se0/1/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x83B1
Progress Ind i = 0x8488 - In-band info or appropriate now available
Sep 21 08:44:07.354: ISDN Se0/1/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x83B1
Progress Ind i = 0x8582 - Destination address is non-ISDN
Sep 21 08:44:07.354: %ISDN-6-CONNECT: Interface Serial0/1/0:0 is now connected to 0120912738 N/A
Sep 21 08:44:07.355: ISDN Se0/1/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x03B1
Sep 21 08:44:10.085: %ISDN-6-DISCONNECT: Interface Serial0/1/0:0 disconnected from 0120912738 , call lasted 2 seconds
Sep 21 08:44:10.085: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x03B1
Cause i = 0x8090 - Normal call clearing
Sep 21 08:44:10.158: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x83B1
Sep 21 08:44:10.158: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x03B1

Ring / No Answer to 08000801248 (bad call)
Sep 21 08:40:48.803: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-type 0x11 is 0x0 0x0, Calling num 035551212
Sep 21 08:40:48.803: ISDN Se0/1/0:23 Q931: Sending SETUP callref = 0x03AF callID = 0x8330 switch = primary-ntt interface = User
Sep 21 08:40:48.803: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref = 0x03AF
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Calling
Party Number i = 0x0080, '0355551212'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '08000801248'
Plan:Unknown, Type:Unknown
Sep 21 08:40:48.926: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8 callref = 0x83AF
Cause i = 0x82E46C - Invalid information element contents
Call State i = 0x01
Sep 21 08:40:48.929: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x83AF
Channel ID i = 0xA98381
Exclusive, Channel 1
Sep 21 08:40:49.791: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x83AF
Progress Ind i = 0x8481 - Call not end-to-end ISDN, may have in-band info
Progress Ind i = 0x8488 - In-band info or appropriate now available
Sep 21 08:40:49.887: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8 callref = 0x83AF
Progress Ind i = 0x8488 - In-band info or appropriate now available
***Alerting and Connect messages are missing here***
Sep 21 08:41:14.742: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x03AF
Cause i = 0x8090 - Normal call clearing
Sep 21 08:41:14.838: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x83AF
Sep 21 08:41:14.839: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x03AF

Debug of ISDN Events:
Good call:
Sep 21 13:10:40.477: ISDN Se0/1/0:23 EVENT: process_pri_call: call id 0x8366, number 0120912738, Guid 42D14D800000, speed 0, call type VOICE, redial No, CSM call No, pdata Yes
Sep 21 13:10:40.604: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8366 calltype 2 CALL_PROCEEDING
Sep 21 13:10:41.482: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8366 calltype 2 CALL_PROGRESS
Sep 21 13:10:42.252: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8366 calltype 2 CALL_PROGRESS
Sep 21 13:10:42.348: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8366 calltype 2 CALL_PROGRESS
Sep 21 13:10:42.444: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8366 calltype 2 CALL_CONNECT
Sep 21 13:10:42.444: %ISDN-6-CONNECT: Interface Serial0/1/0:0 is now connected to 0120912738 N/A
Sep 21 13:10:42.444: ISDN Se0/1/0:23 EVENT: isdn_neighbor_update: NLCB->State 10
Sep 21 13:10:42.444: ISDN Se0/1/0:23 EVENT: isdn_neighbor_update: NLCB->State 10
Sep 21 13:10:42.445: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8366 calltype 2 CALL_PROGRESS
Sep 21 13:10:44.261: %ISDN-6-DISCONNECT: Interface Serial0/1/0:0 disconnected from 0120912738 , call lasted 1 seconds
Sep 21 13:10:44.415: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8366 calltype 2 CALL_CLEARED

Bad call - No connect message:
Sep 21 13:10:21.410: ISDN Se0/1/0:23 EVENT: process_pri_call: call id 0x8365, number 08000801248, Guid 377E22000000, speed 0, call type VOICE, redial No, CSM call No, pdata Yes
Sep 21 13:10:21.582: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8365 calltype 2 CALL_PROCEEDING
Sep 21 13:10:22.461: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8365 calltype 2 CALL_PROGRESS
Sep 21 13:10:22.620: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8365 calltype 2 CALL_PROGRESS
Sep 21 13:10:29.976: ISDN Se0/1/0:23 EVENT: process_rxstate: ces/callid 1/0x8365 calltype 2 CALL_CLEARED

Some info no the T1/ISDN Config:

card type T1 0 1

network-clock synchronization automatic

voice call send-alert

isdn switch-type primary-ntt

trunk group PSTN-TRUNK-GRP
hunt-scheme sequential both up

voice rtp send-recv

controller T1 0/1/0
clock source line primary
description ISDN-PRI-1
framing ESF
linecode B8ZS
pri-group timeslots 1-24

network-clock input-source 1 controller T1 0/1/0

interface Serial0/1/0:23
description D CHANNEL FOR ISDN-PRI-1
no ip address
encapsulation hdlc
isdn switch-type primary-ntt
isdn incoming-voice voice
no cdp enable

[Abhay Singh Reyal]

I would suggest you to engage TELCO directly regarding the issue, as the demarcation point of Cisco Network Topology is the Cisco Gateway which is being used where the PRI is connected. Now you need to open a case with Telco and ask them why the called number is not being answered. As per the ISDN Q.931 signalling it Alerting and Connect message is sent by Provider to gateway. If there is any number plan change that they are expecting that can be definitely changed on CUCM/Gateway.

HTH
Regards
Abhay

Kindly rate all helpful posts !!!

[voip7372]

Thanks.   We're trying to get our vendor out to that office to work with the telco (do some test calls while the telco does a trace).  Hopefully we'll get that arranged soon.  I just wanted to see if anyone had experienced this before and alread knew what the resolution was.  

[Abhay Singh Reyal]

It should be the TELCO who is not processing the signalling as per the requirement. Sure, Keep us posted.

Regards
Abhay

[voip7372 · Accepted solution]

For search purposes in case someone else has a similar problem, here's our resolution...

This was eventually resolved by changing a setting in the SIP profile that was assigned to the SIP trunk in CUCM that goes to the router (router has the ISDN circuit and that router is connected to CUCM via a SIP trunk).

SIP Profile assigned to the SIP trunk in CUCM, under Trunk Specific Configuration, the SIP Rel1XX Options field was set to disabled (which is the default).  Cisco Japan advised changing this to Send PRACK if 1XX contains SDP.   After making that change for the SIP profile assigned to the SIP trunk and resetting the SIP trunk, it works! 

We had a ticket open with Cisco USA previously about this but they said the service provider was to blame.  Our vendor in Japan opened a ticket with Cisco in Japan and they were able to resolve it within a few days.