[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]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/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-04-07 08:10 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
http://bugs.digium.com/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.
====================================================================== 

---------------------------------------------------------------------- 
 (0102828) davidw (reporter) - 2009-04-07 08:10
 http://bugs.digium.com/view.php?id=14802#c102828 
---------------------------------------------------------------------- 
Applying the obvious fix to http://bugs.digium.com/view.php?id=14686 reverts the
behaviour to that in
1.6.0.

Maybe we can track the cause 17 part of the problem against
http://bugs.digium.com/view.php?id=14686
(assuming that will get fixed), leaving the following issues here:

1) The somewhat indeterminate choice between the auto-congest and critical
request paths (although noting that using an explicit IP address v sip.conf
seems to make a fairly consistent difference);

2) The auto-congest path returning an invalid cause code of zero.

I can live with both of these because they are not mimiced by things that
can happen in normal operation on a SIP trunk.

This does imply that http://bugs.digium.com/view.php?id=14686 is now more
severe. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-07 08:10 davidw         Note Added: 0102828                          
======================================================================