[asterisk-bugs] [Asterisk 0014385]: [patch] Unhold fails if first SDP on OK, particularly Cisco CCM 6

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=14385 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14385
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     confirmed
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-02-02 06:39 CST
Last Modified:              2009-12-04 12:31 CST
====================================================================== 
Summary:                    [patch] Unhold fails if first SDP on OK,
particularly Cisco CCM 6
Description: 
Cisco CCM 6 appears never to send SDP on the INVITE, so Asterisk
effectively makes the offer, even when the Cisco is re-inviting because a
CCM hosted phone has gone on hold.  Asterisk sets up its SDP from flags[1]
in the channel private data structure, which means that, if the channel was
on hold, it will offer a=inactive (observed, although a=recvonly also seems
possible).  Even if the CCM intended to unhold, the only possible response
to an a=inactive offer, is a=inactive.  Asterisk should only actually use
saved state if it is making the response.  For an offer, as it looks like
it can never locally hold, it should offer a=sendrecv.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0014448 [patch] chan_sip fails to remove hold w...
====================================================================== 

---------------------------------------------------------------------- 
 (0114778) davidw (reporter) - 2009-12-04 12:31
 https://issues.asterisk.org/view.php?id=14385#c114778 
---------------------------------------------------------------------- 
There is, actually, a signficant difference from the codecs list, in that
the codecs response is allowed to contain capabilities that weren't in the
offer.

On the other hand, Asterisk actually seems to err in the opposite
direction, by always offering the mutually compatible codecs from the last
round, even if that means they drop off one by one (code read on 1.6.1.0),
and it is actually that behaviour which means one cannot directly copy the
codec negotiation logic, as it would never head away from a=inactive!  The
trouble is that this seems to require yet another set of hold state
variables in the pvt structure, or add_sdp needs to know whether it is
offering or answering.  (I think I will go with the latter.) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-04 12:31 davidw         Note Added: 0114778                          
======================================================================