[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-10-17 10:08 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0093896) davidw (reporter) - 2008-10-17 10:08
 http://bugs.digium.com/view.php?id=13545#c93896 
---------------------------------------------------------------------- 
Using the 1.6.0 code, what I think is happening is that:

The native bridge is being trigged by this code, in apps/app_dial.c (or
possible the proceeding or progress cases):

apps/app_dial.c
    703                                 case AST_CONTROL_RINGING:
    704                                         ast_verb(3, "%s is
ringing\n", c->name);
    705                                         /* Setup early media if
appropriate */
    706                                         if (single &&
CAN_EARLY_BRIDGE(peerflags, in, c))
    707                                                
ast_channel_early_bridge(in, c);

When the call fails, this gets run:

   1942         ast_channel_early_bridge(chan, NULL);

which, eventually, ends up in main/rtp.c.  Although that makes a pretence
of handling a null second parameter, it eventually reaches this code:

   1857         if (audio_src_res == AST_RTP_TRY_NATIVE &&
srcpr->get_codec)
   1858                 srccodec = srcpr->get_codec(c1);
   1859         else
   1860                 srccodec = 0;
   1861         if (audio_dest_res == AST_RTP_TRY_NATIVE &&
destpr->get_codec)
   1862                 destcodec = destpr->get_codec(c0);
   1863         else
   1864                 destcodec = 0;

This is slightly weird in that c1 and c0 seem, to me, to be crossed over,
but even without that, I presume the null c1 would result in, at least
destcodec getting set to zero, which is a condition for exiting the
routine.

What I presume was intended to happen, was that a null c1 should cause c0
to be re-invited back to Asterisk.

Have I missed anything here? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2008-10-17 10:08 davidw         Note Added: 0093896                          
======================================================================