[asterisk-bugs] [Asterisk 0013545]: Channel re-invited on destination ringing not re-invited back if ringing abandoned.

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=13545 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   13545
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
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:              
====================================================================== 
Date Submitted:             2008-09-23 08:25 CDT
Last Modified:              2008-09-23 10:10 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0092786) davidw (reporter) - 2008-09-23 10:10
 http://bugs.digium.com/view.php?id=13545#c92786 
---------------------------------------------------------------------- 
The simplest model that seems to produce this effect is something like
(phone number changed):

exten => 6183,1,Answer
exten => 6183,n,Dial(SIP/988888888888 at 192.168.10.10,10)
exten => 6183,n,Dial(Agent/3003,,t) ' flag to prevent re-invite out.

If one has a SIP phone directly, rather than the Agent as a fallback, the
re-invite gets undone.  If one doesn't pre-answer, in that case, there are
no re-invites and the PSTN call is connected with a local bridge, which
may, itself be a problem, but we will always have answered.

With the fragment above, the SIP history, for the caller, is:

  * SIP Call
1. Rx              INVITE / 1 INVITE / sip:6183 at 192.168.130.116
2. AuthChal        Auth challenge sent for  - nc 0
3. TxRespRel       SIP/2.0 / 1 INVITE - 407 Proxy Authentication Required
4. SchedDestroy    32000 ms
5. Rx              ACK / 1 ACK / sip:6183 at 192.168.130.116
6. Rx              INVITE / 2 INVITE / sip:6183 at 192.168.130.116
7. CancelDestroy   
8. Invite          New call: OGI0ZGEzOTZmMTg4MjcwMzlhNTBkMTBmMDRhZGQzODY.
9. AuthOK          Auth challenge succesful for djw-messenger
10. NewChan         Channel SIP/djw-messenger-09f826a8 - from
OGI0ZGEzOTZmMTg4MjcwM
11. TxResp          SIP/2.0 / 2 INVITE - 100 Trying
12. TxRespRel       SIP/2.0 / 2 INVITE - 200 OK
13. Rx              ACK / 2 ACK / sip:6183 at 192.168.130.116
14. ReInv           Re-invite sent
15. TxReqRel        INVITE / 102 INVITE - -UNKNOWN-
16. Rx              SIP/2.0 / 102 INVITE / 200 OK
17. TxReq           ACK / 102 ACK - -UNKNOWN-

and one ends up with the originator bridged thus:

  Audio IP:               192.168.10.10 (Outside bridge)

and the agent bridged thus:

  Audio IP:               192.168.130.116 (local)

I will attach the full SIP show channel's for this case. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-09-23 10:10 davidw         Note Added: 0092786                          
======================================================================