[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:                     new
Asterisk Version:           1.4.33 
JIRA:                        
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-07-09 07:04 CDT
====================================================================== 
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)
====================================================================== 

---------------------------------------------------------------------- 
 (0124382) davidw (reporter) - 2010-07-09 07:04
 https://issues.asterisk.org/view.php?id=17613#c124382 
---------------------------------------------------------------------- 
OK.  Looks like we deferred analyzing this in detail.  However, this is my
initial internal analysis, which may give some clues, although it really
needs more explanation of what we were doing (I'm not claiming this meets
the bug reporting guidelines, yet):

Tester's Report (some application specifics replaced by lower level
details).

Using AMI, I made an outbound call to Party A (6902). 

Once the call was established I performed an AMI Redirect to Party B (6902
– using the same directory number as Party A). 

Both Party A and Party B calls were terminated. The error show in Asterisk
was... 

NoOp('SIP/cisco1-08ef80e8', '') in new stack 
-- Executing [6902 at internal:52005] Dial('SIP/cisco1-08ef80e8',
'SIP/6902 at cisco1,20') in new stack 
[2009-07-09 12:06:48.356] WARNING[21619]: app_dial.c:1485 dial_exec_full:
Skipping dialing interface 'SIP/6902 at cisco1' again since it has already
been dialed 
== Spawn extension (internal, 6902, 52005) exited non-zero on
'SIP/cisco1-08ef80e8' 

Developer's Analysis.

The message is referring to a mechanism that ensures that when you dial
numbers in parallel, Asterisk will not try to set up more than one
connection to a number, even if it is specified multiple times. 

I haven't looked at the code, but the symptoms suggest that party A is
being included in that list. 

What is more worrying is that Dial operation appears to be returning a
call complete indication! That means we lose control of the call. It
appears to be deliberate, but isn't explained in the code. I think it may
be intended to deal with cases where a local channel is in the list of
channels to be tried. It may be trying to get the CHANUNAVAIL status back
quickly. 

I think this will really need running svn blame, to find out which edit
put this in, then trying to understand why it is done, if we want to be
sure that there is a bug, rather than an awkward new feature. 

Specifically, this sets the completed return code: 

if (!outgoing) { 
strcpy(pa.status, 'CHANUNAVAIL'); 
if (fulldial == num_dialed) { 
res = -1; 
goto out; 
} 

fulldial is only incremented for the case of already dialling the
interface and outgoing == 0 will be true, as it has rejected the only
available outgoing interface. 

It sets the datastore that stores the dialled interfaces as inheritable. I
think that is done to ensure the local channel sees, it but is probably
having the side effect of making it inherit from the call to party A, and
more worryingly, it may be left over from a failed party B call. Can you
call party B again if the timed out on the first attempt? It does look like
it may forget failed interfaces, but maybe it doesn't forget successful
ones until the call completes. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-09 07:04 davidw         Note Added: 0124382                          
======================================================================