[asterisk-bugs] [Asterisk 0011157]: Asterisk does not send a provisional response at every minute

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=11157 
====================================================================== 
Reported By:                rjain
Assigned To:                twilson
====================================================================== 
Project:                    Asterisk
Issue ID:                   11157
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     closed
Asterisk Version:           1.6.1-beta1 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2007-11-04 16:29 CST
Last Modified:              2009-09-02 19:23 CDT
====================================================================== 
Summary:                    Asterisk does not send a provisional response at
every minute
Description: 
The issue here is that Asterisk does not send a non-100 response at every
minute for calls that are in the provisional response state. This causes
most UACs and/or proxies to terminate the call after 3 minutes. There are
many legitimate reasons why a call could remain in an unanswered state for
more than 3 minutes such as early-media (183), call queuing (182), call
forwarding (181) and ringing (180). 

Following is quote from section 13.3.1.1 of RFC 3261 which explains what a
UAS should do under such a circumstance:

   If the UAS desires an extended period of time to answer the INVITE,
   it will need to ask for an "extension" in order to prevent proxies
   from canceling the transaction.  A proxy has the option of canceling
   a transaction when there is a gap of 3 minutes between responses in a
   transaction.  To prevent cancellation, the UAS MUST send a non-100
   provisional response at every minute, to handle the possibility of
   lost provisional responses.

This issue was first reported by Alex Balashov on the asterisk-dev mailing
list:
http://lists.digium.com/pipermail/asterisk-dev/2007-November/030341.html.
I've reproduced this problem and collected wireshark and debug traces,
which are attached to this bug report.

====================================================================== 

---------------------------------------------------------------------- 
 (0110095) svnbot (reporter) - 2009-09-02 19:23
 https://issues.asterisk.org/view.php?id=11157#c110095 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 215774

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r215774 | twilson | 2009-09-02 19:23:58 -0500 (Wed, 02 Sep 2009) | 32
lines

Merged revisions 215758 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r215758 | twilson | 2009-09-02 18:31:04 -0500 (Wed, 02 Sep 2009) | 25
lines
  
  Merged revisions 215682 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r215682 | twilson | 2009-09-02 16:41:22 -0500 (Wed, 02 Sep 2009) | 18
lines
    
    Re-send non-100 provisional responses to prevent cancellation
    
    From section 13.3.1.1 of RFC 3261:
    
       If the UAS desires an extended period of time to answer the INVITE,
       it will need to ask for an "extension" in order to prevent proxies
       from canceling the transaction. A proxy has the option of canceling
       a transaction when there is a gap of 3 minutes between responses in
a
       transaction. To prevent cancellation, the UAS MUST send a non-100
       provisional response at every minute, to handle the possibility of
       lost provisional responses.
    
    (closes issue https://issues.asterisk.org/view.php?id=11157)
    Reported by: rjain
    Tested by: twilson
    
    Review: https://reviewboard.asterisk.org/r/315/
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=215774 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-09-02 19:23 svnbot         Checkin                                      
2009-09-02 19:23 svnbot         Note Added: 0110095                          
======================================================================