[asterisk-bugs] [Asterisk 0017613]: [patch] 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-12 08:24 CST
====================================================================== 
Summary:                    [patch] 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)
====================================================================== 

---------------------------------------------------------------------- 
 (0128825) kaii (reporter) - 2010-11-12 08:24
 https://issues.asterisk.org/view.php?id=17613#c128825 
---------------------------------------------------------------------- 
correct, that is exactly what i did to avoid that kind of problem.
i did not commit a patch, because i'm sure this is not the correct
solution for the issue. 

the check if a peer is already in the list of "dialed_interfaces" is
intentional and of good use to prevent loops redirection loops that can
easily eat memory and CPU resources of no use:

SIP/10 (e.g. snom phone) has a forward to "20" which is executed as
"Local/20 at context" by app_dial, the new local channel then dials SIP/20.
SIP/20 (e.g. snom phone) has a forward to "10" which is executed as
"Local/10 at context" by app_dial, the new local channel then dials SIP/10.

Without the check of "dialed_interfaces" this would produce an endless
(fastly growing) count of Local and SIP channels, resulting in growing
memory, growing CPU usage, and growing garbage in the log files. 

This is an architectural problem:
Asterisk can not know if a User Agent is going to forward the call
(because it has been locally set up in the phone) and thus can not detect
call forwarding forehand.  
To prevent loops, it needs some magic which was intended to be the list of
"dialed_interfaces". This works pretty for the use case of call forwarding
loops like i described in this note, but fails for the use case where a
user does a blind transfer.
Unfortunately, SIP UAs (eg. snom phones) use "302 Moved Temporarily" both
for blind transfer ("forward" on demand) and call forward ("forward"
statically).

A possibly good workaround for this would be to check if a device returned
either directly "302 Moved Temporarily" after receiving the INVITE or first
"180 Ringing" and then "302 Moved Temporarily". When the phone sends "180
Ringing" that would mean the call was not directly deflected.

Caveats:
 - I dont know if all UAs do it this way, maybe there are UAs that answer
an INVITE with 180+302 even if a direct call forward is set up. snom
directly responds an INVITE with 302, when local call forwarding is set
up.
 - This is a slightly bigger and more complicated change, thus is haven't
tried to implement this yet. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-11-12 08:24 kaii           Note Added: 0128825                          
======================================================================