[asterisk-bugs] [Asterisk 0013545]: Channel re-invited on destination ringing not re-invited back if ringing abandoned.
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Dec 18 11:15:51 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13545
======================================================================
Reported By: davidw
Assigned To: file
======================================================================
Project: Asterisk
Issue ID: 13545
Category: Channels/chan_sip/General
Reproducibility: always
Severity: major
Priority: normal
Status: closed
Asterisk Version: 1.4.21.2
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2008-09-23 08:25 CDT
Last Modified: 2008-12-18 11:15 CST
======================================================================
Summary: Channel re-invited on destination ringing not
re-invited back if ringing abandoned.
Description:
An incoming SIP call is answered by an agent and then AMI transferred to a
PSTN line on Cisco CCM. The Cisco provides SDP on the Ringing response and
Asterisk re-invites the incoming call immediately it gets that response.
The Dial command times out and cancels the outgoing call, but at no time
does the re-invite get undone, even when the dialplan eventually
successfully returns the call to the agent. The result is a silent call.
The un-re-invite can be forced by parking the call and then unparking it
(in this case with an AMI Originate which queues it back to an agent).
This is a big problem for us as it is important for our application that
as many calls as possible have their speech path removed from the Asterisk
system.
I am also concerned that specifying multiple destinations in the Dial
command, may not inhibit the re-invite, leading to conflicting re-invites,
in the order of the Ringing events. However, I haven't confirmed that this
is the case.
======================================================================
----------------------------------------------------------------------
(0096631) svnbot (reporter) - 2008-12-18 11:15
http://bugs.digium.com/view.php?id=13545#c96631
----------------------------------------------------------------------
Repository: asterisk
Revision: 165605
_U branches/1.6.1/
U branches/1.6.1/main/rtp.c
------------------------------------------------------------------------
r165605 | file | 2008-12-18 11:15:51 -0600 (Thu, 18 Dec 2008) | 18 lines
Merged revisions 165599 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
................
r165599 | file | 2008-12-18 13:13:32 -0400 (Thu, 18 Dec 2008) | 11 lines
Merged revisions 165591 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r165591 | file | 2008-12-18 13:11:42 -0400 (Thu, 18 Dec 2008) | 4
lines
Only care about a compatible codec for early bridging if we are
actually bridging to another channel. If we are not we actually want to
bring the audio back to us.
(closes issue http://bugs.digium.com/view.php?id=13545)
Reported by: davidw
........
................
------------------------------------------------------------------------
http://svn.digium.com/view/asterisk?view=rev&revision=165605
Issue History
Date Modified Username Field Change
======================================================================
2008-12-18 11:15 svnbot Checkin
2008-12-18 11:15 svnbot Note Added: 0096631
======================================================================
More information about the asterisk-bugs
mailing list