[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-03 11:44 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0114664) davidw (reporter) - 2009-12-03 11:44
 https://issues.asterisk.org/view.php?id=14385#c114664 
---------------------------------------------------------------------- 
Although this patch seems to work in the context of the existing Asterisk,
I am more and more becoming convinced that the whole send/recv only
negotiation logic is wrong, and that this problem wouldn't arise, and the
original patch wouldn't have needed to be done to 1.4, if it were better.

I think the negotiation should be done in the same way as codec
negotiation, with local, peer and joint values, and coding the permissions
in each direction as separate bits.  Currently one may not need the local
values, but consideration of https://issues.asterisk.org/view.php?id=16524
changes this.  It is also possible that
https://issues.asterisk.org/view.php?id=16373 could be done more cleanly with
such a structure.  (For the benefit
of anyone who might try this in parallel, I have chosen to name the working
flags relative to their sender, in my prototype code, so a local recvonly
combines with a remote sendonly.)

One other thing I have noticed is that the coding of PAGE2_CALL_ONHOLD
does not have orthogonal values for the two bits, i.e. if you combine
active with sendonly, you get inactive.  I haven't found a path through the
code that actually breaks, but it ends up using ast_set_flag as though it
were a masked assignment, when it is actually a simple bitwise or, and can
never clear bits.  I'm prototyping on the basis of one bit for sendonly and
one bit for recvonly, with only the recvonly one (corresponding to upstream
sendonly) actually resulting in hold state processing.

This removes a don't know case, which is treated the same as sendrecv, but
something would have to be done with that in order to fix
https://issues.asterisk.org/view.php?id=16313. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-03 11:44 davidw         Note Added: 0114664                          
======================================================================