[cisco-voip] q931 cause codes

Tue Sep 20 18:44:34 EDT 2011

according to what you said, VLT is munging bits as it displays stuff to you.
did it really show those zeros when you were looking at it?

Wellnitz, Erick A. erick.wellnitz at kattenlaw.com
via<http://mail.google.com/support/bin/answer.py?hl=en&ctx=mail&answer=1311182>
 puck.nether.net to Wes, cisco-voip
show details Sep 19 (1 day ago)

This is what I see in VLT detailed view:

Message Header

08 02 7E C2 45

-- DISCONNECT, pd = 8, callref = 0x7EC2

Information Element(s)

08 02 81 E6

-- Cause i = 0x0810E6 - Recovery on timer expiry  <<<---- Appears to have
added two zeros where they shouldn't be.

Entire Message:

0010: 08 02 7E C2 45 08 02 81 E6

On Tue, Sep 20, 2011 at 1:33 PM, Wes Sisk <wsisk at cisco.com> wrote:

> Heuristically recover on timer expire is either a setup or connect message
> sent and SetupAck or ConnectAck not received.
> This also happens if you call a destination with no call forward no answer
> coverage (common in europe).
> I believe this is also used when TCP session setup for h323/sip fails.
>
> *sometimes* in SDL traces you will see a message from SDLTimerThread
> indicating the specific timer that expires and triggers this event.  Example
> of a timer expiring from SDLTimerThread:
> 306031106 |2011/09/09 09:21:30.590 |100 |SdlSig    |SubscriptionTimer
>                |
> active                         |Notifier(1,100,114,66441)
>  |SdlTimerService(1,100,3,1)
>   |1,100,63,1.366120^10.114.11.114^SEPC89C1DA34FE7
> |[R:H-H:460,N:5994,L:14,V:0,Z:0,D:0]
>
> This is a signal from SDLTimerService to Notifier process indicating
> SubscriptionTimer has expired.
>
> The only way to know for certain is to look at the complete signaling for
> the call. If you're in VLT looking at SDI traces then you likely have the
> right data, it's just a matter of interpreting it.  SDL's can be helpful as
> well.
>
> /wes
>
>
>
>
> On Sep 20, 2011, at 12:39 PM, Wellnitz, Erick A. wrote:
>
> CAR shows the same as the sdi trace.****
> ** **
> 102****
> Call terminated when timer expired; a recovery routine executed to recover
> from the error.****
> ** **
> Is there any way to determine which timer expired? ****
> ** **
> ** **
> *From:* Wes Sisk [mailto:wsisk at cisco.com]
> *Sent:* Monday, September 19, 2011 3:28 PM
> *To:* Wellnitz, Erick A.
> *Cc:* cisco-voip at puck.nether.net voip
> *Subject:* Re: [cisco-voip] q931 cause codes****
> ** **
> Oh, and CUCM internal codes are documented in the CAR guide:****
>
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/6_0_1/car/carcdrdef.html#wp1062680
> ****
> ** **
> /wes****
> ** **
> ** **
> On Sep 19, 2011, at 4:24 PM, Wes Sisk wrote:****
> ** **
> Externally (communicated to to h.323 gateway or MGCP gateway) the cause
> codes do have to be in the subset of q.931 defined codes.****
> ** **
> Internally (for call legs inside CUCM) there can be more cause codes. SDI
> logs contain both internal and external codes so you could see either there.
>  What is the complete trace line where you see that cause code?****
> ** **
> ** **
> I *think* in 0x0810E6 you're going to focus on 0x10 = 16(decimal) = normal
> call clearing.  It would be good to see the original SDI or SDL trace line
> to confirm.****
> ** **
> http://www.cisco.com/en/US/docs/ios/11_0/debug/command/reference/disdn.html
> ****
> ** **
> Regards,****
> Wes****
> ** **
> On Sep 19, 2011, at 3:59 PM, Wellnitz, Erick A. wrote:****
> ** **
> Okay…are the q931 disconnect messages not consistent between debug isdn
> q931 and the sdi logs?****
>  ****
> SDI log (via VLT) shows cause code of 0x0810E6 but this doesn’t coincide
> with the Cisco documentation re: q931 cause codes. ****
>  ****
>
> http://www.cisco.com/en/US/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml#topic1
> ****
>  ****
>  ****
>  ****
> *ERICK A. WELLNITZ *
> Network Engineer
> *Katten Muchin Rosenman LLP*
> 525 W. Monroe Street / Chicago, IL 60661-3693
> p / (312) 577-8041
> erick.wellnitz at kattenlaw.com / www.kattenlaw.com****
>  ****
>
> ===========================================================****
>
> CIRCULAR 230 DISCLOSURE: Pursuant to Regulations Governing Practice Before the Internal Revenue****
>
> Service, any tax advice contained herein is not intended or written to be used and cannot be used****
>
> by a taxpayer for the purpose of avoiding tax penalties that may be imposed on the taxpayer.****
>
> ===========================================================****
>
> CONFIDENTIALITY NOTICE:****
>
> This electronic mail message and any attached files contain information intended for the exclusive****
>
> use of the individual or entity to whom it is addressed and may contain information that is****
>
> proprietary, privileged, confidential and/or exempt from disclosure under applicable law.  If you****
>
> are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or ****
>
> distribution of this information may be subject to legal restriction or sanction.  Please notify****
>
> the sender, by electronic mail or telephone, of any unintended recipients and delete the original ****
>
> message without making any copies.****
>
> ===========================================================****
>
> NOTIFICATION:  Katten Muchin Rosenman LLP is an Illinois limited liability partnership that has****
>
> elected to be governed by the Illinois Uniform Partnership Act (1997).****
>
> ===========================================================****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
> ** **
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
> ** **
>
>
> _______________________________________________
> 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/20110920/b0dc0e0c/attachment.html>