[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 02:34 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.

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

---------------------------------------------------------------------- 
 abalashov - 11-05-07 02:34  
---------------------------------------------------------------------- 
I was not even aware this was an implementational bug, especially with the
1.4.x tree.  :-)  It was just very strange;  I swore that the UAS
implementation is supposed to retransmit provisional replies a lot more
frequently than the interval tha I saw associated with the UACs aborting
the call leg.

I would be curious to know the cumulative effect of retransmissions of
early media / SDP messages of class 183 specifically on the continuity of
the media stream, in the case of music-on-hold with queues, my original
index case.  My guess would be that if the media is already being passed
backward to the caller, the SDP information in the retransmission that
holds it down probably just reaffirms it and does not disrupt it in any
way.  Can anyone confirm that this would be true?  Or would the music
restart each time the 183 was repeated?

Also, what if the SDP information passed back from the UAS in subsequent
hold-down retransmits conflicts with the original media stream's port
assignment parameters, etc?  Does the spec mandate that subsequent
revisions to the media stream within the same dialogue be adhered to, in
the case of provisional messages (rather than well-known implementations
that utilise this precedence, like re-INVITEs). 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-05-07 02:34  abalashov      Note Added: 0073067                          
======================================================================