[asterisk-bugs] [Asterisk 0012548]: SIP channel protocol illegally reverses direction when ringing channel AMI redirected (to parked channel)

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12548 
====================================================================== 
Reported By:                davidw
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   12548
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
Asterisk Version:           SVN 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 11463 
Request Review:              
====================================================================== 
Date Submitted:             2008-04-29 09:47 CDT
Last Modified:              2009-03-13 13:29 CDT
====================================================================== 
Summary:                    SIP channel protocol illegally reverses direction
when ringing channel AMI redirected (to parked channel)
Description: 
An outgoing call to a SIP channel was initiated using AMI Originate; the
first channel was a Local/ channel.  Whilst the call was still ringing, the
Local channel was AMI Redirected to a parked channel in the parking lot
(and drops out of the configuration).  A short time later, the call fails
within Asterisk, with the following diagnostics:

[Apr 27 11:09:03] WARNING[10117]: chan_sip.c:1948 retrans_pkt: Maximum
retries e
xceeded on transmission 4dd8e816320e6fac293336971fb18544 at 192.168.130.116
for seq
no 102 (Critical Response)
[Apr 27 11:09:03] WARNING[10117]: chan_sip.c:1972 retrans_pkt: Hanging up
call 4
dd8e816320e6fac293336971fb18544 at 192.168.130.116 - no reply to our critical
packe
t.

The destination phone continues to ring for some time after this.

If the call is answered before the Redirect, there is no problem.

Looking at the SIP traces indicates that Asterisk starts sending OK's (for
NOTIFY) in the same direction as it sent the NOTIFY's for the call setup. 
The called end ignores these.  If it answers after Asterisk has abandoned
it, it Asterisk ignores its OK's, in the correct direction, resulting in
the phone timing out before it considers the call dead.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013747 Indications are not passed from old pee...
====================================================================== 

---------------------------------------------------------------------- 
 (0101741) davidw (reporter) - 2009-03-13 13:29
 http://bugs.digium.com/view.php?id=12548#c101741 
---------------------------------------------------------------------- 
Looking at the description for http://bugs.digium.com/view.php?id=13747, I think
there is a good chance that
the fix for that covered this issue.  As noted, though we are committed to
our work around now, and it probably isn't going to be practicable to
recreate the exact scenario.  (I have a feeling we have since take
advantage of the local channel for other reasons.)

The test described in the review does sound as though it covers our
original scenario, though.

In the next week or two we will try a version that includes the
http://bugs.digium.com/view.php?id=13747
fix, so should soon know if that fixes the problem for our workaround
version, although I'm fairly confident that it will. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-13 13:29 davidw         Note Added: 0101741                          
======================================================================