[asterisk-bugs] [Asterisk 0012713]: SIP Protocol Violation when REFER rejected in sip_transfer (Cisco CCM, post answer), and Transfer application misclaims success.

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12713 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12713
Category:                   Channels/chan_sip/Transfers
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.20 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             05-23-2008 12:59 CDT
Last Modified:              06-04-2008 10:21 CDT
====================================================================== 
Summary:                    SIP Protocol Violation when REFER rejected in
sip_transfer (Cisco CCM, post answer), and Transfer application misclaims
success.
Description: 
A call from Cisco CCM was answered and then transferred back to a different
extension on the Cisco.

Asterisk first reported a successful TRANSFERSTATUS, then tried to use a
REFER method.  This was rejected as unsupported.  Asterisk responded with
BYE, which the Cisco accepted.  However it continued to try to send REFERs,
which the Cisco, of course, rejected, because the session reference had
been deleted by the BYE!
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0010052 NOTIFY race condition when state change...
related to          0011848 Incorrect dialog matching and requests ...
====================================================================== 

---------------------------------------------------------------------- 
 davidw - 06-04-08 10:21  
---------------------------------------------------------------------- 
Note that the other aspect of this is that the transfer fails after the
dialplan has been told it has worked.  Looking further at this, I notice
this issue is highlighted in the comments, although they say they are
waiting on some form of return code variable and that now seems to exist.

That means the dialplan cannot simply fall back to using Dial, even it it
hadn't completely lost the original call.

In practice transfer didn't prove useful to use for other reasons, which
is why I only considered the problem minor. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-04-08 10:21  davidw         Note Added: 0087809                          
======================================================================