[cisco-voip] Cisco 2821 & Nortel MICS Back-to-Back (PRI) Issues

Wes Sisk wsisk at cisco.com
Thu Jun 6 14:39:58 EDT 2013 

Human interpretation:

IOS sends Progress message with Progress Indicator IE
IOS sends Connect with Progress Indicator and Connected Number IE
Peer device responds with STATUS message complaining that one of the IEs is not valid. When the peer detects that it knows the call state to be 3. I *think* state 3 is call proceeding. Call enters that state after Call_Proc message. So either Progress or Connect message contains the offending IE.

Jun  6 13:59:36.309 EDT: ISDN Se0/1/0:23 Q931: TX -> PROGRESS pd = 8  callref = 0x8002
        Progress Ind i = 0x8188 - In-band info or appropriate now available
Jun  6 13:59:40.497 EDT: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x8002
        Progress Ind i = 0x8188 - In-band info or appropriate now available
        Connected Number i = 0x8080, '??????????'
Jun  6 13:59:40.537 EDT: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8  callref = 0x0002
        Cause i = 0x81E3 - Information element not implemented
        Call State i = 0x03
Jun  6 13:59:40.541 EDT: ISDN Se0/1/0:23 **ERROR**: Ux_Status: STATUS call state mismatch with invalid cause: cause 0x63, state 0xA, peer state 0x3
Jun  6 13:59:40.541 EDT: ISDN Se0/1/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x8002
        Cause i = 0xC2E5 - Message not compatible with call state

If IOS is sending an unsupported IE then it's possible the router and Nortel are configured for different ISDN protocols. the ISDN protocol ( or switch type) generally mandates the valid messages and IEs in each state.

1. check the isdn switch type on each side
2. let's hear from IOS experts on this mailer if there's a way to suppress the Progress Indicator or Connected Number IEs.

-Wes



On Jun 6, 2013, at 2:00 PM, Gary T. Giesen <giesen at snickers.org> wrote:

Called Party Number changed to ?????????? to protect the innocent...

Jun  6 13:59:34.325 EDT: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8  callref = 0x0002
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA18397
                Preferred, Channel 23
        Called Party Number i = 0x80, '??????????'
                Plan:Unknown, Type:Unknown
Jun  6 13:59:34.325 EDT: ISDN Se0/1/0:23 Q931: Received SETUP  callref = 0x8002 callID = 0x0087 switch = primary-ni interface = Network
Jun  6 13:59:34.345 EDT: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x8002
        Channel ID i = 0xA98397
                Exclusive, Channel 23
Jun  6 13:59:36.309 EDT: ISDN Se0/1/0:23 Q931: TX -> PROGRESS pd = 8  callref = 0x8002
        Progress Ind i = 0x8188 - In-band info or appropriate now available
Jun  6 13:59:40.497 EDT: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x8002
        Progress Ind i = 0x8188 - In-band info or appropriate now available
        Connected Number i = 0x8080, '??????????'
Jun  6 13:59:40.537 EDT: ISDN Se0/1/0:23 Q931: RX <- STATUS pd = 8  callref = 0x0002
        Cause i = 0x81E3 - Information element not implemented
        Call State i = 0x03
Jun  6 13:59:40.541 EDT: ISDN Se0/1/0:23 **ERROR**: Ux_Status: STATUS call state mismatch with invalid cause: cause 0x63, state 0xA, peer state 0x3
Jun  6 13:59:40.541 EDT: ISDN Se0/1/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x8002
        Cause i = 0xC2E5 - Message not compatible with call state
Jun  6 13:59:40.541 EDT: ISDN Se0/1/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x0002
Jun  6 13:59:40.573 EDT: ISDN Se0/1/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x0002


On Thu, Jun 6, 2013 at 1:47 PM, Wes Sisk <wsisk at cisco.com> wrote:
based on this line:
Jun  6 12:08:57.771 EDT: ISDN Se0/1/0:23 **ERROR**: Ux_Status: STATUS call state mismatch with invalid cause: cause 0x63, state 0xA, peer state 0x3

I suspect you might be hitting an issue here callerid is provided in an unsupported IE. that causes a status message. that status message contains a call state. the call has already progressed beyond that call state so you get a mismatch, no mechanism for recovery, and a drop.

If the 2821 were using MGCP back to CUCM then this would be relevant:
http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCeg56289

As is, we need to confirm this is what is happening and then look to our IOS Voice participants for any available options.

You say "outgoing call from perspective of MICS" - is it configured to send name outbound? can you get 'debug isdn q931' in addition to the below? What is the ISDN switch type? sharing as much of the config as you are comfortable with would help.

*if* it is callerid causing the problem you might try disabling callerid under the voice port. I think it's 'no caller-id enable' under the voice port.

-wes

On Jun 6, 2013, at 12:36 PM, Gary T. Giesen <giesen at snickers.org> wrote:

I've got a Cisco 2821 with a PRI card configured with SIP trunking. I'm trying to interface with a PRI card on a Nortel MICS. Incoming calls work fine, but outgoing calls (from the perspective of the MICS) ring and die a half second after the called party picks up.

I've including some debug, but not sure what's relevant (I'm not a TDM guy) so let me know what else you need...

Jun  6 12:08:53.526 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: source id 0x300, call id 0x6A, event 0x341 (pre-ccb recovery)
Jun  6 12:08:53.526 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: L3_event 0090
Jun  6 12:08:53.526 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: call id 0x1 cref 0x6A event 0x8001 Source->L3
Jun  6 12:08:53.526 EDT: ISDN Se0/1/0:23 CC: CCPCC_CallIdle: event 0x90 b channel 0 nfas int_id 0 call_id 0x6A
Jun  6 12:08:53.530 EDT: ISDN Se0/1/0:23 CC: CCPRI_AcceptChanId: Negotiated int_id 0 bchan 0 cref 0x8001 call_id 0x006A lo_chan 23 final int_id/bchan 0/23 cause 0
Jun  6 12:08:53.554 EDT: ISDN Se0/1/0:23 Error: Invalid DSL (0)  CC: CCPRI_Go: source id 0x500, call id 0x0, event 0x4A (pre-ccb recovery)
Jun  6 12:08:53.554 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: call_id 0x6A cref 0x8001 event 0x4A Source->HOST
Jun  6 12:08:53.554 EDT: ISDN Se0/1/0:23 CC: CCPCC_CallOffered: event = 0x4A b channel 23 nfas int_id 0 call_id 0x6A
Jun  6 12:08:55.378 EDT: ISDN Se0/1/0:23 Error: Invalid DSL (0)  CC: CCPRI_Go: source id 0x500, call id 0x0, event 0x4E (pre-ccb recovery)
Jun  6 12:08:55.378 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: call_id 0x6A cref 0x8001 event 0x4E Source->HOST
Jun  6 12:08:55.378 EDT: ISDN Se0/1/0:23 CC: CCPCC_CallRoutingIn: executing with event = 4E in state = CALL ROUTING_IN
Jun  6 12:08:57.731 EDT: ISDN Se0/1/0:23 Error: Invalid DSL (0)  CC: CCPRI_Go: source id 0x500, call id 0x0, event 0x4E (pre-ccb recovery)
Jun  6 12:08:57.731 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: call_id 0x6A cref 0x8001 event 0x4E Source->HOST
Jun  6 12:08:57.731 EDT: ISDN Se0/1/0:23 CC: CCPCC_CallRoutingIn: executing with event = 4E in state = CALL ROUTING_IN
Jun  6 12:08:57.731 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: source id 0x300, call id 0x6A, event 0x341 (pre-ccb recovery)
Jun  6 12:08:57.731 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: L3_event 0092
Jun  6 12:08:57.731 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: dispatching event 0x92 call id 0x6A cref 0x8001 Source->L3
Jun  6 12:08:57.731 EDT: ISDN Se0/1/0:23 CC: CCPCC_CallRoutingIn: executing with event = 92 in state = CALL ROUTING_IN
Jun  6 12:08:57.771 EDT: ISDN Se0/1/0:23 **ERROR**: Ux_Status: STATUS call state mismatch with invalid cause: cause 0x63, state 0xA, peer state 0x3
Jun  6 12:08:57.807 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: source id 0x300, call id 0x6A, event 0x341 (pre-ccb recovery)
Jun  6 12:08:57.807 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: L3_event 0099
Jun  6 12:08:57.807 EDT: ISDN Se0/1/0:23 CC: CCPRI_Go: dispatching event 0x99 call id 0x6A cref 0x8001 Source->L3
Jun  6 12:08:57.807 EDT: ISDN Se0/1/0:23 CC: CCPCC_CallConnected: event 0x99 b channel 23 nfas int_id 0 call_id 0x6A
Jun  6 12:08:57.811 EDT: ISDN Se0/1/0:23 Error: Invalid DSL (0)  CC: CCPRI_Go: source id 0x500, call id 0x0, event 0x57 (pre-ccb recovery)


Thanks!

GTG
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130606/f58621b0/attachment.html>

More information about the cisco-voip mailing list