[asterisk-bugs] [Asterisk 0009566]: 603 declined do not stop after CANCEL in blind xfer

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=9566 
====================================================================== 
Reported By:                atca_pres
Assigned To:                oej
====================================================================== 
Project:                    Asterisk
Issue ID:                   9566
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 61686 
Disclaimer on File?:        Yes 
Request Review:              
====================================================================== 
Date Submitted:             04-20-2007 08:05 CDT
Last Modified:              08-29-2007 17:42 CDT
====================================================================== 
Summary:                    603 declined do not stop after CANCEL in blind xfer
Description: 
Sc?nario :
A : Aastra 9113i 10.4.122.235
B : Mediatrix 1104 10.4.121.237
C : Mediatrix 2102 10.4.117.254
* : 10.4.119.245

A Calls B
B Answers
Call OK
B Flash Hook and calls C
B hangs up while C is ringing (blind transfer)
Call redirected BUT :
Look at packet 58 - 603 declined
It's not answered by the unit right away. The unit is in the process of
canceling the call avec the Notify (packet 57). Instead of acking right
away, the unit CANCEL the call (Packet 62) and the CANCEL is accepted by *.
(This is unusual but it is supported in the RFC since nothing prevent the
UAC and UAS to cancel the same call at the same time)

The problem is : After accepting the call, * should stop sending the 603
declined. You can see that it does not by looking in packet :
67,69,71,75,81,83 and * repeat the message even if all the 603 are acked
before (the ack to the first 603 is right after the CANCEL (packet 65 or
66). 

Since the ACK to the CANCEL are EXACTLY the same as the ACK of the 603,
maybe * think it is a resent packet and ignore it ?

Anyway, * should have destroyed the call after it has received the ACK to
it's 200 OK (packet 64)
====================================================================== 

---------------------------------------------------------------------- 
 qwell - 08-29-07 17:42  
---------------------------------------------------------------------- 
oej, do we want to commit this? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-29-07 17:42  qwell          Note Added: 0069672                          
======================================================================