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

Asterisk Bug Tracker noreply at bugs.digium.com
Fri May 8 12:14:00 CDT 2009


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-05-08 12:13 CDT
====================================================================== 
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...
====================================================================== 

---------------------------------------------------------------------- 
 (0104472) davidw (reporter) - 2009-05-08 12:13
 http://bugs.digium.com/view.php?id=14385#c104472 
---------------------------------------------------------------------- 
There still seems to be some sort of compatibility problem with the Cisco. 
The CCM sends IP=0.0.0.0, a=inactive, to which Asterisk responds
a=inactive.  Then, very soon afterwards, it tries again with no SDP, as
though it didn't like the original response.  Asterisk, with the patch
applied, responds a=sendrecv, to which Cisco ACKS a=sendonly.

Asterisk then sends a=recvonly to party B.  When I first tried this, I
used an X-Lite as party B and it dropped the call in response to that. 
Using CCM for party B didn't result in a dropped call, although the other
party reported only intermittent music on hold, which may well be a
configuration/network issue.

I'm now going to have a look at some of the traces I took when alternating
CCM between held and unheld..... 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-08 12:13 davidw         Note Added: 0104472                          
======================================================================




More information about the asterisk-bugs mailing list