Re: Cisco Q.931 debugs

ken.vance · ‎04-21-2011

Hi all,

I am trying to troubleshoot an intermittent voice issue using debug isdn q931, on a Cisco 2811 with an isdn pri. I am trying to decode the last two digits in : Cause i = 0x80E50F

From the Cisco documentation I understand they are optional diagnostic values and may/may not appear but cannot find their meaning (when they do appear).

Does anyone know what the value 0x0f means, or can they provide a link to the right webpage?

Also, can anyone explain the basic meaning of:

ISDN Se0/1/0:15 **ERROR**: L3_BadPeerMsg: event 0x5A .......

Help gratefully appreciated!

Ken

D_Lebedev · ‎04-21-2011

Good day.

Seems it can be ios based bug.

Whish IOS you're using.

Which type of router?

ken.vance · ‎04-25-2011

Hi,

Can you tell me why you think its an IOS bug? just curious!

Its a Cisco 2811, IOS c2800nm-spservicesk9-mz.124-10c.bin

Any more info needed, let me know!

Ken

antyeung · ‎04-21-2011

http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

E5

Message not compatible with call state

The remote equipment receives an expected message that does not correspond to the current state of the connection.

This issue occurs due to a D-channel error.

I would look at the entire q931 message exchange leading up to this error. If this problem happens several times compare the q931 message exchange in each instance to see if there is a common q931 message right before you see the error in the console. If there is I would inquire about that particular q931 message and whether your configured switch type supports that message in the particular call state that it's in.

ken.vance · ‎04-25-2011

Hi,

This occurs intermittently throughout the customers working day, always at the same point and with the same error.

Any ideas?

Here is the debug:

#
Apr 20 09:55:40.059: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0F7F
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Facility i = 0x91AA068001008201008B0100A11402020B7106042B0C0900300880064C2E4E65696C
        Calling Party Number i = 0x0980, 'XXXXXXX'
                Plan:Private, Type:Unknown
        Called Party Number i = 0x80, 'XXXX'
                Plan:Unknown, Type:Unknown
        High Layer Compat i = 0x9181
Apr 20 09:55:40.067: ISDN Se0/1/0:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0x8F7F
        Channel ID i = 0xA98381
                Exclusive, Channel 1
Apr 20 09:55:41.347: ISDN Se0/1/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0F7F
        Called Party Number i = 0x80, 'X'
                Plan:Unknown, Type:Unknown
Apr 20 09:55:41.583: ISDN Se0/1/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0F7F
        Called Party Number i = 0x80, 'X'
                Plan:Unknown, Type:Unknown
Apr 20 09:55:41.747: ISDN Se0/1/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0F7F
        Called Party Number i = 0x80, 'X'
                Plan:Unknown, Type:Unknown
Apr 20 09:55:41.959: ISDN Se0/1/0:15 Q931: RX <- INFORMATION pd = 8 callref = 0x0F7F
        Sending Complete
        Called Party Number i = 0x80, 'X'
                Plan:Unknown, Type:Unknown
Apr 20 09:55:41.983: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8F7F
Apr 20 09:55:42.843: ISDN Se0/1/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8F7F
        Facility i = 0x9FAA068001008201008B0100A12502020789020101301C8400A51806052B0C024E01300F8004313238380A0104040434373731
        Progress Ind i = 0x8188 - In-band info or appropriate now available
Apr 20 09:55:42.859: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8F7F
        Connected Number i = 0x0080, '4771'
Apr 20 09:55:42.859: ISDN Se0/1/0:15 Q931: RX <- STATUS pd = 8 callref = 0x0F7F
        Cause i = 0x80E4 - Invalid information element contents
Apr 20 09:55:42.863: ISDN Se0/1/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x8F7F
        Cause i = 0x80E5 - Message not compatible with call state

Apr 20 09:55:42.867: ISDN Se0/1/0:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0F7F
Apr 20 09:55:42.871: ISDN Se0/1/0:15 **ERROR**: Ux_BadMsg: Invalid Message for call state 19, call id 0xF7F, call ref 0x8F7F, event 0xF
Apr 20 09:55:42.871: ISDN Se0/1/0:15 Q931: TX -> STATUS pd = 8 callref = 0x8F7F
Cause i = 0x80E50F - Message not compatible with call state
Apr 20 09:55:42.871: ISDN Se0/1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0F7F
Apr 20 09:55:42.883: ISDN Se0/1/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0F7F
Cause i = 0x80E5 - Message not compatible with call state
Apr 20 09:55:42.891: ISDN Se0/1/0:15 **ERROR**: L3_BadPeerMsg: event 0x5A cr 0x8F7F callid 0x0

I can see the router transmits a release whilst waiting for the connect_ack.

Any ideas on how to resolve this? I thought perhaps a timer expiring but unsure which one applies.

Ken

antyeung · ‎04-26-2011

The provider switch may be complaining about the "Connected Number" information element that we send in the ISDN CONNECT message-

     Apr 20 09:55:42.859: ISDN Se0/1/0:15 Q931: TX -> CONNECT pd = 8 callref = 0x8F7F
       Connected Number i = 0x0080, '4771'
     Apr 20 09:55:42.859: ISDN Se0/1/0:15 Q931: RX <- STATUS pd = 8 callref = 0x0F7F
        Cause i = 0x80E4 - Invalid information element contents

I would see if there's a way to not send this IE in the ISDN CONNECT message and retest. Can you copy/paste the configurations you have under Serial 0/1/0?

ken.vance · ‎04-26-2011

Hi,

Here is the configuration :

interface Serial0/1/0:15

no ip address

encapsulation hdlc

no logging event link-status

no snmp trap link-status

isdn switch-type primary-qsig

isdn overlap-receiving T302 6000

isdn incoming-voice voice

isdn send-alerting

isdn sending-complete

no cdp enable

end

The site has a Mitel IP-PBX with the phone subnet trunked off the main LAN port, if that helps at all.

Ken

antyeung · ‎04-28-2011

Nothing really stares out at me. I can't recall if there's a CLI command where you can control the ISDN call leg of sending the "Connected Number" in the ISDN connect. What type of signaling protocol is being used on the other call leg, H.323? Do you know if the device that the Cisco gateway is peering with can remove the "Connected Number" IE?