[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:33 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:33  
---------------------------------------------------------------------- 
I don't think sending multiple 183s will confuse any devices as long as the
SDPs contained in these 183s is exactly the same. These 183s obviously
carry the same to-tag which indicates that they are being originated by the
same UAS. When the UAC processes an inbound 183 SDP on an existing
early-dialog, it sees that the version number in the o= line has not
changed and thus it knows that it MUST NOT alter any media processing.

If a UAC causes media to change in such a condition then it is seriously
broken. That UAC is does not comply to RFC 3261 or RFC 2543.  

Also note that multiple 183s can happen due to interworking w/ PSTN
anyways. If Asterisk receives multiple PROGRESS messages on Q.931, each
will map to a 183 from Asterisk to the UAC. 

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