[asterisk-bugs] [Asterisk 0014802]: Cause code for INVITE timeout doesn't match intent of code and semi-randomly chooses between DIALSTATUS of BUSY and CONGESTION
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri May 22 12:55:25 CDT 2009
The following issue has been set as RELATED TO issue 0014686.
======================================================================
https://issues.asterisk.org/view.php?id=14802
======================================================================
Reported By: davidw
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14802
Category: Channels/chan_sip/General
Reproducibility: always
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.6.0.6
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-04-01 07:03 CDT
Last Modified: 2009-05-22 12:55 CDT
======================================================================
Summary: Cause code for INVITE timeout doesn't match intent
of code and semi-randomly chooses between DIALSTATUS of BUSY and CONGESTION
Description:
With 1.6.0.1 we were observing a cause code of 18, and also possibly of 0,
for invites that timed out because of a connection failure (we are testing
a failure case in which a Cisco CCM goes down, by pulling its network
cable). When we tried to do this as a more controlled test with 1.6.0.6,
we found that we were always getting cause 17. Whilst, as note in
https://issues.asterisk.org/view.php?id=14683,
I don't believe that 18 is an appropriate encoding of this condition, at
least it doesn't clash with a code that can actually be generated by normal
SIP events in Asterisk, whereas 17 is AST_CAUSE_USER_BUSY, the standard
subscriber engaged code.
Moreover, we found that we sometimes got a DIALSTATUS of BUSY and
sometimes of CONGESTION. The former is associated with a critical request
timeout log message and the latter with an Auto-congest log message. My
guess is that the latter corresponds to the cause 0 we observed for
1.6.0.1.
Examination of the no reply to critical request code path shows that it is
actually trying to set a cause code of 18, but will not do so if one is
already set. On that basis, I argue that the use of code 17 is a bug, as
it is not what the code is trying to do.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0014686 Regression: <a href="view.php?id=13867"...
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
2009-05-22 12:55 lmadsen Relationship added related to 0014686
======================================================================
More information about the asterisk-bugs
mailing list