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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11157 
====================================================================== 
Reported By:                rjain
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11157
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.13  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             11-04-2007 16:29 CST
Last Modified:              11-05-2007 06:12 CST
====================================================================== 
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.

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

---------------------------------------------------------------------- 
 rjain - 11-05-07 06:12  
---------------------------------------------------------------------- 
The UAS MUST repeat the last 101-199 range 1XX (whatever that 1XX happened
to be) that it sent to the UAC at every minute. 

If the previous 1XX contained an SDP, then the keep-alive 1XX will contain
the exact same SDP. As a matter of rule in the SIP protocol, a UAS is not
allowed to change the SDP between 1XX and 2XX, let alone the SDP in
keep-alive 1XXs. Since the UAC will see the same o= line version number
across various keep-alive 1XX SDPs it knows that nothing has changed with
respect to the media stream. The whole purpose of the keep-alive 1XXs is to
refresh the early dialog at the UAC and proxies. This phenomenon has no
effect on media streams whatsoever. 

Regarding the point made about why we don't use RE-INVITEs for session
refresh in this case, a RE-INVITE can not be initiated unless the previous
INVITE transaction has successfully completed. In this case, the previous
INVITE transaction is still going. This is in fact one of the fundamental
reasons why SIP had to resort to keep-alive 1XXs.

Section 13.3.1.1 in RFC 3261 describes this is good enough detail. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-05-07 06:12  rjain          Note Added: 0073077                          
======================================================================