[cisco-voip] debug isdn q931 invalid information element

[Ryan Ratliff]

Either the telco doesn't think you have a full PRI or they think the last b-channel is down or busy.   I've also seen this from a telco that didn't like the isdn plan/type that was getting sent.

In either case there are more applicable disconnect causes they could send.   Try changing the channel order to start at 1 instead of 23 and see if the same call is successful.

-Ryan

On Jan 30, 2010, at 11:52 AM, Jason Aarons (US) wrote:

12.4.24T2 with CME7.1/H323
 
SDCVWRT-5204-2#
Jan 30 16:37:55.915: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0x3 is 0x2 0x1, Calling num 2123805999
Jan 30 16:37:55.915: ISDN Se0/0/0:23 Q931: Sending SETUP  callref = 0x00C0 callID = 0x8041 switch = primary-5ess interface = User
Jan 30 16:37:55.915: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x00C0
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98397
                Exclusive, Channel 23
        Calling Party Number i = 0x2180, '2123805999'
                Plan:ISDN, Type:National
        Called Party Number i = 0xA1, '9044914588'
                Plan:ISDN, Type:National
Jan 30 16:37:55.979: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x80C0
        Cause i = 0x82E418 - Invalid information element contents
dial-peer voice 91904 pots
 destination-pattern 91..........
 incoming called-number .
 direct-inward-dial
 port 0/0/0:23
 forward-digits 10
!
dial-peer voice 4 voip
 destination-pattern 4...
 session target ipv4:10.89.224.1
 incoming called-number .
 codec g711ulaw
 
Here is what telco is saying….anyone else seen this?
 
3109:
The switch received a Q.931 SETUP message from the customer premises equipment (CPE) on a primary rate interface (PRI) D-channel, but the message contained an invalid channel identification information element (IE).
 
2019:
The switch transmitted an information frame and did not receive an  acknowledgement in T200 time units from the far end. The switch proceeded to poll the far end with a LAPD receiver ready (RR) or receiver not ready (RNR) frame. The RR or RNR was re-transmitted N200 times (with each RR or RNR retransmitted every T200 time units) and got no response from the far end. An RR or RNR frame should be the response
 
 
 
 
Jason Aarons
Consultant
Dimension Data
<image001.png>   904.338.3245
<image002.gif>    904-338-3245
<image003.gif>   Jason.Aarons at us.didata.com
<image004.gif>   Jason.Aarons at us.didata.com
                     
For more information about Dimension Data, please go to www.dimensiondata.com
 
For urgent issues notify your Project Manager, for 24x7 support contact the Dimension Data NOC at +1-800-974-6584 or Cisco TAC at +1-800-553-2447.
 


Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you.

_______________________________________________
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/20100131/eb78978a/attachment.html>