[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-01 08:37 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0102534) davidw (reporter) - 2009-04-01 08:37
 http://bugs.digium.com/view.php?id=14802#c102534 
---------------------------------------------------------------------- 
svn.digium.com has been broken for a least a day, so I can't use the web
view onto the archive to definitively identify the patch, but this patch
that was introduced between 1.6.0 and 1.6.0.6 is probably the cause of the
BUSY path problem.  I think the CONGESTION path was always broken. 
Comparing the 1.6.0 archive (possibly modified, but not at this point) and
the 1.6.0.6 archive copies of chan_sip.c:

@@ -4270,8 +4299,11 @@
 
        res = update_call_counter(p, INC_CALL_RINGING);
 
-       if (res == -1)
+       if (res == -1) {
                return res;
+       } else {
+               ast->hangupcause = AST_CAUSE_USER_BUSY;
+       }
 
        p->callingpres = ast->cid.cid_pres;
        p->jointcapability =
ast_translate_available_formats(p->capability, p->prefcodec);

Note, except possibly for the exact left hand side line numbers, this is a
difference between two versions already licensed to Digium.  It is provided
solely to identify the revision that has already been made. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-01 08:37 davidw         Note Added: 0102534                          
======================================================================