ISDN PRI Sending Different Type/Plan When Dialed From Jabber vs. C7962

[Michael Mertens]

I'm migrating my outgoing calls off a VGW as it's connected ISDN Switch is being decommed by the carrier. The VGW I'm migrating it to, is handling all our incoming DIDs. When I send calls out the other VGW (connected to same carrier) from a C7962 to my cell phone, the ISDN Q931 debug/call setup looks perfect. However, when I initiate a call from my Jabber client (same DN with same CSS, and Device-level CSS is the same and Device Pool is the same as the C7962), the ISDN Plan/Type appears to be changed and the Bearer Capability is different. The carrier ends-up sending a DISCONNECT. I ran DNA for the same dialed number (my cell) originating the call from Jabber verses the C7962- call flow and dialed number is the same for both analysis. Please see the two different ISDN Q931 debugs for each. I'm beside myself on what could be changing the ISDN type/plan.

Good Call from C7962 

NLFCSP1MDFVGWTM01#
44231217: Mar 14 18:08:52.027: ISDN Se0/0/1:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num 15183059292
44231218: Mar 14 18:08:52.027: ISDN Se0/0/1:23 Q931: Sending SETUP callref = 0x00D2 callID = 0xEF70 switch = primary-ni interface = User
44231219: Mar 14 18:08:52.031: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8 callref = 0x00D2
Sending Complete
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9838B
Exclusive, Channel 11
Calling Party Number i = 0x1181, '15183059292'
Plan:ISDN, Type:International
Called Party Number i = 0x80, '15189254753'
Plan:Unknown, Type:Unknown
44231220: Mar 14 18:08:52.231: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x80D2
Channel ID i = 0xA9838B
Exclusive, Channel 11
44231221: Mar 14 18:08:53.779: ISDN Se0/0/1:23 Q931: RX <- ALERTING pd = 8 callref = 0x80D2
Progress Ind i = 0x8488 - In-band info or appropriate now available
44231222: Mar 14 18:08:55.643: ISDN Se0/0/1:23 Q931: RX <- CONNECT pd = 8 callref = 0x80D2
Progress Ind i = 0x8482 - Destination address is non-ISDN
44231223: Mar 14 18:08:55.643: ISDN Se0/0/1:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x00D2
NLFCSP1MDFVGWTM01#

Incomplete Call from Jabber
NLFCSP1MDFVGWTM01#
44231189: Mar 14 18:05:43.732: ISDN Se0/0/1:23 Q931: pak_private_number: Invalid type/plan 0x1 0x1 may be overriden; sw-type 13
44231190: Mar 14 18:05:43.732: ISDN Se0/0/1:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num 5183059292
44231191: Mar 14 18:05:43.732: ISDN Se0/0/1:23 Q931: Sending SETUP callref = 0x00D0 callID = 0xEF6E switch = primary-ni interface = User
44231192: Mar 14 18:05:43.732: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8 callref = 0x00D0
Sending Complete
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA9838B
Exclusive, Channel 11
Calling Party Number i = 0x1181, '5183059292'
Plan:ISDN, Type:International
Called Party Number i = 0x80, '15189254753'
Plan:Unknown, Type:Unknown
44231193: Mar 14 18:05:43.984: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x80D0
Channel ID i = 0xA9838B
Exclusive, Channel 11
44231194: Mar 14 18:05:46.764: ISDN Se0/0/1:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x80D0
Cause i = 0x84D8 - Incompatible destination
44231195: Mar 14 18:05:46.764: ISDN Se0/0/1:23 Q931: TX -> RELEASE pd = 8 callref = 0x00D0
44231196: Mar 14 18:05:46.780: ISDN Se0/0/1:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x80D0
44231197: Mar 14 18:05:59.804: ISDN Se0/0/1:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x0052
Cause i = 0x8A90 - Normal call clearing
44231198: Mar 14 18:05:59.804: ISDN Se0/0/1:23 Q931: TX -> RELEASE pd = 8 callref = 0x8052
44231199: Mar 14 18:05:59.824: ISDN Se0/0/1:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0052
NLFCSP1MDFVGWTM01#undebug all


Thank you for any input you can give.

Mike

[Maren Mahoney]

From the first debug:

Calling Party Number i = 0x1181, '15183059292' <-- Note the leading 1
Plan:ISDN, Type:International

From the second debug:

Calling Party Number i = 0x1181, '5183059292' <-- Note the lack of a leading 1
Plan:ISDN, Type:International

Your provider is rejecting the Peru caller ID as not associated with your circuit. And a Peru caller ID is not compatible with the US target.

Maren

[Roger Kallberg]

From what I can see in your shared debugs the type and plan is the same on both calls.

Call from 7962
Calling Party Number i = 0x1181, '15183059292'
Plan:ISDN, Type:International
Called Party Number i = 0x80, '15189254753'
Plan:Unknown, Type:Unknown

Call from Jabber 
Calling Party Number i = 0x1181, '5183059292'
Plan:ISDN, Type:International
Called Party Number i = 0x80, '15189254753'
Plan:Unknown, Type:Unknown

Is there something I’m missing or overlooking?

[Maren Mahoney · Accepted solution]

Dialing 11-digits (1 XXX XXX XXXX) in the US is technically an international call with a country code of 1. This is accepted by most carriers in the US as long as the 11-digits is accompanied by a TON of International. With the 10-digit number and a TON of International, the caller ID appears to the carrier as Peru (country code 51).

Many US carriers require 'legit' caller ID in order to process a call. CLID from "Peru" isn't that and I'm presuming that is the reason the carrier is rejecting the call. So the CLID needs to be sent as 10-digits with a TON of "National" or as 11-digits with the TON of International.

The ISDN circuit, of course, doesn't care if the call is from a hard phone or a Jabber client so it has to be something about the signaling or digits. As the CLID is the 'difference' between the two calls, along with the wrong TON on the non-working call, it stands to reason this is the issue causing the call reject.

Maren

[Roger Kallberg]

I agree, sounds feasible to me. I didn’t even look at the numbers sent as calling numbers, presumably as the OP wrote about type and plan being different and I could not see that being the case, so I guess I overlooked the fact that the numbers were different. Thanks for pointing that out.

[Elliot Dierksen]

Jabber supports additional codecs that the 7962 does not. You might also be having issues because of this line from the jabber call.

Transfer Capability = Unrestricted Digital

The 7962 call sends this.

Transfer Capability = Speech

[Michael Mertens]

All, Thanks for all the input, and apologies about sending the conversation down the "leading 1"/International vs. Nation Type Plan. I thought I had cleaned that up earlier. It is now DEFINITELY cleaned up- please see the new debugs below with the DISCONNECT cause code "Incompatible Destination". To Elliot's point, I wonder why the call leaves from a Jabber end-point with a "Transfer Capability" of Unrestricted Digital" and the C7962 shows "Speech". This blows my mind as far as ISDN calling- that an end-point can influence the Q931 call setup, and I have no idea where in CUCM (or GW) this happens!

I am going to bring this back to the carrier to see if they can explain the "why" of the incompatible destination. The interesting point is that when I route the calls back over the other GW, the Jabber calls still go out with "Unrestricted Digital" and that circuit is fine. Interesting note: The PRI which works with "Unrestricted Digitial" cross-connects to a Carrier VGW with an ISDN switch interfacee, and converts it to IP on the backend. Whereas the PRI that doesn't work with Jabber's "Unrestricted Digital" interfaces to a classic ISDN Switch. Please see new debugs below and THANK YOU FOR THE INPUT!!!

Jabber

44247549: Mar 15 12:17:36.908: ISDN Se0/0/1:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num 15183059292
44247550: Mar 15 12:17:36.908: ISDN Se0/0/1:23 Q931: Sending SETUP callref = 0x00D9 callID = 0xEF77 switch = primary-ni interface = User
44247551: Mar 15 12:17:36.908: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8 callref= 0x00D9
Sending Complete
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98385
Exclusive, Channel 5
Calling Party Number i = 0x1181, '15183059292'
Plan:ISDN, Type:International
Called Party Number i = 0x80, '15189254753'
Plan:Unknown, Type:Unknown
44247552: Mar 15 12:17:37.136: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x80D9
Channel ID i = 0xA98385
Exclusive, Channel 5
44247553: Mar 15 12:17:40.204: ISDN Se0/0/1:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x80D9
Cause i = 0x84D8 - Incompatible destination
44247554: Mar 15 12:17:40.204: ISDN Se0/0/1:23 Q931: TX -> RELEASE pd = 8 callref = 0x00D9
44247555: Mar 15 12:17:40.232: ISDN Se0/0/1:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x80D9

C7962:

44247680: Mar 15 12:21:34.890: ISDN Se0/0/1:23 Q931: Applying typeplan for sw-type 0xD is 0x1 0x1, Calling num 15183059292
44247681: Mar 15 12:21:34.890: ISDN Se0/0/1:23 Q931: Sending SETUP callref = 0x00DA callID = 0xEF78 switch = primary-ni interface = User
44247682: Mar 15 12:21:34.890: ISDN Se0/0/1:23 Q931: TX -> SETUP pd = 8 callref = 0x00DA
Sending Complete
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98384
Exclusive, Channel 4
Calling Party Number i = 0x1181, '15183059292'
Plan:ISDN, Type:International
Called Party Number i = 0x80, '15189254753'
Plan:Unknown, Type:Unknown
44247683: Mar 15 12:21:35.170: ISDN Se0/0/1:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x80DA
Channel ID i = 0xA98384
Exclusive, Channel 4
44247684: Mar 15 12:21:38.142: ISDN Se0/0/1:23 Q931: RX <- ALERTING pd = 8 callref = 0x80DA
Progress Ind i = 0x8488 - In-band info or appropriate now available
44247685: Mar 15 12:21:40.546: ISDN Se0/0/1:23 Q931: RX <- CONNECT pd = 8 callref = 0x80DA
Progress Ind i = 0x8482 - Destination address is non-ISDN
44247686: Mar 15 12:21:40.546: ISDN Se0/0/1:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x00DA
C7962 Over Spine Works

NLFCSP1MDFVGWTM01#

[Maren Mahoney · Accepted solution]

For Jabber: Bearer Capability i = 0x8890 - Which is a 64K data call

For 7962: Bearer Capability i = 0x8090A2 - Which is G711ulaw

So I agree with @Elliot Dierksen that this is a bearer issue.

One way to fix this would be to manually set the ISDN voice-port in your router with "bearer-cap speech" to force only speech through that port.

If this is an MGCP-controlled ISDN circuit there is probably a setting in CUCM for this as well.

Maren

[Michael Mertens · Accepted solution]

Elliott I think nailed it...(though I don't know the solution yet). Looks like Jabber is influencing the Bearer Capability Information Element. According to table 8-6 in the below URL (I LOVE CiscoPress books), Jabber is sending 0x8890-64 Kbps vs. C7962 0x8090A2=G711 ulaw. I don't know if this can be changed on the H323 gateway but have asked our carrier to pursue allowing that IE, as our other TG/PRI circuits do.

[Roger Kallberg · Accepted solution]

As @Maren Mahoney wrote you can set this on the voice port in IOS, it doesn't matter if it's H.323 or SIP. See this example from one of our voice gateways in Germany.

voice-port 0/1/0:15
 cptone DE
 bearer-cap Speech
!
voice-port 0/1/1:15
 cptone DE
 bearer-cap Speech

For MGCP I don't remember how to do it as it's been very long since I last did anything with that type of voice gateway.

[Michael Mertens]

Sorry, The CiscoPress article:
ISDN Specifications > Integrated Services Digital Network Primer | Cisco Press

[Michael Mertens · Accepted solution]

So after much testing and research, and with Elliot's mention of codecs, and noting Jabber calls were initiating a Q931 Bearer Capability IE of "Unrestricted digital" verses C7962s sourced an Information Element code for G711ulaw, I changed the CUCM H323 gateway config to require an MTP. Now jabber calls ISDN calls originate with an Q931 Bearer Capability of "Speech" like the C7962s. and my calls are accepted/complete.

As I was writing this, I noticed Roger's input and suggestion of adding "bearer-cap Speech" under the voice port- this ALSO worked!!! (And I think I'm going to use this method for my change control)

Thanks all for your interest, input and knowledge sharing!!!

Mike

[Michael Mertens]

And Maren's input!!! How did I miss that this AM??!!! I could have fixed this at 7:02 AM!!! Thanks Maren!!!