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

---------------------------------------------------------------------- 
 (0114769) davidw (reporter) - 2009-12-04 11:34
 https://issues.asterisk.org/view.php?id=14385#c114769 
---------------------------------------------------------------------- 
My gut feeling is that one should be downgrading sendrecv to recvonly (and
sendonly to inactive) if one gets a 0.0.0.0 address for the RTP.

However, it looks to me that an inbound a=sendonly or inactive can
currently set a state which forces update_call_counter to be called with
DEC_CALL_LIMIT during cleanup, but a 0.0.0.0 address doesn't.  I'm pretty
sure this test is redundant, as SIP_INC_COUNT is an alternative trigger for
this behaviour and the count only actually seems to get changed if it was
set.  However, I'm reluctant to make 0.0.0.0 set don't-send, in case I've
missed something.

(Incidentally, although the coding of the PAGE2 flags is a bit perverse
(the two conditions aren't really orthogonal, and can't cope with recvonly,
it shouldn't break the current code any further because the no hold state
is coded as both bits clear.) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-12-04 11:34 davidw         Note Added: 0114769                          
======================================================================