[asterisk-bugs] [Asterisk 0017613]: After a blind transfer by the calling party the transferees peer cannot be dialed again within the same call

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17613 
====================================================================== 
Reported By:                ramonpeek
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17613
Category:                   Channels/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.33 
JIRA:                       SWP-1833 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-07-09 05:38 CDT
Last Modified:              2010-11-08 03:33 CST
====================================================================== 
Summary:                    After a blind transfer by the calling party the
transferees peer cannot be dialed again within the same call
Description: 
After a blind transfer by the calling party the transferees peer cannot be
dialed again within the same call. This ONLY occurs when dialing through a
Local channel.

Asterisk will show this warning on the CLI>

[Jul  9 12:18:37] WARNING[27865]: app_dial.c:1296 dial_exec_full: Skipping
dialing interface 'SIP/401' again since it has already been dialed


NOTE: See steps to reproduce (in advanced view)
====================================================================== 

---------------------------------------------------------------------- 
 (0128684) kaii (reporter) - 2010-11-08 03:33
 https://issues.asterisk.org/view.php?id=17613#c128684 
---------------------------------------------------------------------- 
Another way to reproduce, it hit me while testing several internal call
scenarios:

simple dialplan:
exten => _XX,1(dial),Dial(SIP/${EXTEN})
exten => _XX,dial+101,Busy()

1. SIP/10 dials SIP/20:

    -- Executing [execute_call at macro-internanruf:7]
Dial("SIP/10-00000018", "SIP/20") in new stack
    -- Called 20
    -- SIP/20-00000019 is ringing

2. SIP/20 then sends a 302 redirect ("sip blind transfer") and targets
extension 30:

    -- Got SIP response 302 "Moved Temporarily" back from 10.0.0.149
    -- Now forwarding SIP/10-00000018 to 'Local/30 at internal' (thanks to
SIP/20-00000019)
     -- Executing [30 at internal] Dial("Local/30 at internal-1b8d,2", "SIP/30")
in 
    -- Called 30
    -- SIP/30-00000020 is ringing
    -- Local/30 at internal-1b8d,1 is ringing

3. SIP/30 now wants to redirect back to SIP/20 via 302 redirect and hits
the bug:

    -- Got SIP response 302 "Moved Temporarily" back from 10.0.0.150
    -- Now forwarding SIP/10-00000018 to 'Local/30 at internal' (thanks to
SIP/20-00000019)
     -- Executing [20 at internal] Dial("Local/20 at internal-1b8d,2", "SIP/20")
in new stack
[Nov  5 16:53:34] WARNING[27403] app_dial.c: Skipping dialing interface
'SIP/20' again since it has already been dialed

It seems, that in case of a SIP 302 "moved temporarily", the redirecting
peer (here: SIP/20) is (incorrectly) not removed from the list of dialed
interfaces.
after the 302 redirect the peer SIP/20 is "not_inuse" again and should be
able to receive this call again.

i quickly worked around this in my setup by disabling the check if a peer
is in the list of dialed_interfaces. i know this is not a general solution. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-08 03:33 kaii           Note Added: 0128684                          
======================================================================