[asterisk-bugs] [Asterisk 0017878]: [patch] chan_sip fails to remove hold when receving a reINVITE without SDP
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Aug 24 09:11:38 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17878
======================================================================
Reported By: frawd
Assigned To: mnicholson
======================================================================
Project: Asterisk
Issue ID: 17878
Category: Channels/chan_sip/Interoperability
Reproducibility: always
Severity: minor
Priority: normal
Status: confirmed
Target Version: 1.6.2.13
Asterisk Version: 1.6.2.11
JIRA: SWP-2064
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2010-08-17 11:05 CDT
Last Modified: 2010-08-24 09:11 CDT
======================================================================
Summary: [patch] chan_sip fails to remove hold when receving
a reINVITE without SDP
Description:
Patch for issue https://issues.asterisk.org/view.php?id=14448 never made it to
trunk so all versions above 1.4
suffer this problem.
Here is an updated patch for 1.6.2.11.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0014448 [patch] chan_sip fails to remove hold w...
======================================================================
----------------------------------------------------------------------
(0126266) frawd (reporter) - 2010-08-24 09:11
https://issues.asterisk.org/view.php?id=17878#c126266
----------------------------------------------------------------------
I'll certainly take a look at your patch, because I don't understand the
explanation very well. Still I think I get more or less what the objective
is.
A few comments about the above:
Sending an INVITE without an offer is quite common, I've seen this with
Cisco, Nortel and Huawei proxies. I've looked into it and it's part of some
method called "third party call control" (3pcc), it complies with all RFCs
involved and even has a best practice RFC (RFC-3725).
It is indeed legitimate to start a call in a=recvonly, the only thing is
that I have yet to see a real-world application that would need to do
that.
Also in the few cases I've seen for this particular problem, the
hold-unhold thing happens in less than 5ms, I'm not even sure that music on
hold had time to send a single 20ms packet.
Issue History
Date Modified Username Field Change
======================================================================
2010-08-24 09:11 frawd Note Added: 0126266
======================================================================
More information about the asterisk-bugs
mailing list