[asterisk-bugs] [Asterisk 0017878]: [patch] chan_sip fails to remove hold when receving a reINVITE without SDP

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17878 
====================================================================== 
Reported By:                frawd
Assigned To:                mnicholson
====================================================================== 
Project:                    Asterisk
Issue ID:                   17878
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     confirmed
Target Version:             1.6.2.13
Asterisk Version:           1.6.2.11 
JIRA:                       SWP-2064 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-17 11:05 CDT
Last Modified:              2010-08-24 06:57 CDT
====================================================================== 
Summary:                    [patch] chan_sip fails to remove hold when receving
a reINVITE without SDP
Description: 
Patch for issue https://issues.asterisk.org/view.php?id=14448 never made it to
trunk so all versions above 1.4
suffer this problem.

Here is an updated patch for 1.6.2.11.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014448 [patch] chan_sip fails to remove hold w...
====================================================================== 

---------------------------------------------------------------------- 
 (0126262) davidw (reporter) - 2010-08-24 06:57
 https://issues.asterisk.org/view.php?id=17878#c126262 
---------------------------------------------------------------------- 
Remote party initiates hold.

Remote party does re-invite, but without intent to remove hold (e.g.) it
is changing the state of a different media stream (I know one of the
current bugs is that it doesn't track these states for each stream).  It
might also do a re-invite as a keep alive (that is one of the uses of
re-invite).

For some reason (maybe it is a Cisco), it doesn't send SDP on the
request.

As Asterisk didn't want the hold, it should send a=sendrecv, but it should
not remove the hold until, it gets back a=sendrecv, as, in the cases above,
there was no change in the hold state and the response will contain the
same a=sendonly, as before.

Note that it is perfectly legitimate to start a call in a=recvonly state. 
I don't think Asterisk can do this, but the wording in the RFC doesn't bar
a call from being in a hold from the very beginning.  I believe what the
RFC is saying is simply that one should not take account of previously
received SDP from the remote party, at this level of the protocol.

Treating an SDP-less re-invite as unhold, can result in a hold immediately
followed by an unhold, and, in practical terms, cause a glitch in the music
on hold.

(I've actually have code that tries to do this right (with the existing
single media stream problem), but it is intertwined with other changes.  I
remember the remote party's desired hold state, and only change it on
receiving SDP from them, but make a distinction between first offer and
response, sending my wants on the first offer and including the remote
party's request in a response.

In our case, we also want to correctly report holds initiated by Asterisk,
to the held party, so we also have to factor in the local media direction
attribute requirements.  Doing so is essential for Transfer() to work with
some switches, and is also what you should do if you are going to send
music on hold; if nothing else, in the latter role, it causes the user
interface on the phone to correctly indicate the call is being held from
the other end of the wire.

As that is a feature change, it would have to be separated out before
submitting a patch.) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-08-24 06:57 davidw         Note Added: 0126262                          
======================================================================