[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
Tue May 19 09:47:47 CDT 2009


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/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:                     assigned
Asterisk Version:           1.4.21.2 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2008-09-23 08:25 CDT
Last Modified:              2009-05-19 09:47 CDT
====================================================================== 
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0105006) svnbot (reporter) - 2009-05-19 09:47
 https://issues.asterisk.org/view.php?id=13545#c105006 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 195451

_U  branches/1.6.1/
U   branches/1.6.1/channels/chan_sip.c

------------------------------------------------------------------------
r195451 | file | 2009-05-19 09:47:47 -0500 (Tue, 19 May 2009) | 21 lines

Merged revisions 195449 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r195449 | file | 2009-05-19 11:43:54 -0300 (Tue, 19 May 2009) | 14 lines
  
  Merged revisions 195448 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r195448 | file | 2009-05-19 11:41:45 -0300 (Tue, 19 May 2009) | 7
lines
    
    Fix a bug where direct RTP setup would partially occur even when
disabled if the calling channel was answered.
    
    (issue https://issues.asterisk.org/view.php?id=13545)
    Reported by: davidw
    (issue https://issues.asterisk.org/view.php?id=14244)
    Reported by: mbnwa
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=195451 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-05-19 09:47 svnbot         Checkin                                      
2009-05-19 09:47 svnbot         Note Added: 0105006                          
======================================================================




More information about the asterisk-bugs mailing list