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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14385 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14385
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.0.1 
Regression:                 No 
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-02-17 13:33 CST
====================================================================== 
Summary:                    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...
====================================================================== 

---------------------------------------------------------------------- 
 (0100265) davidw (reporter) - 2009-02-17 13:33
 http://bugs.digium.com/view.php?id=14385#c100265 
---------------------------------------------------------------------- 
I think what was confusing me about Asterisk apparently sending inactive on
the OK to the hold, without SDP on the invite was that CCM has first sent
re-invite to address 0.0.0.0 on the invite, then, immediately sent invite
with no SDP.

Subsequently both hold and unhold seem to generate invite with no SDP,
even though the phone state changes.

I wonder if it doesn't like Asterik's response to first hold and is then
somewhat confused, with the lack of code for a resume on no SDP getting
Asterisk locked into hold?

I'll try and sanitise the traces and attach them tomorrow.  But,
basically:

> Invite SDP
< Trying
< OK SDP
> ACK

> Invite SDP
< Trying
< OK SDP
> Ack

Press Hold

< Invite SDP a=inactive c= IN 0.0.0.0
> Trying
> OK SDP a=inactive
< Ack


Unhold

< Invite
> Trying
> OK SDP a=inactive
< Ack a=inactive c= non null

Hold

< Invite
> Trying
> OK SDP a=inactive
< Ack a=inactive c= non null


(This differs slightly from the original scenario in that I have
eliminated our application from the equation, and that has a side effect
that it is possible to re-invite the RTP after the initial setup.) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-02-17 13:33 davidw         Note Added: 0100265                          
======================================================================