[asterisk-bugs] [JIRA] Closed: (ASTERISK-16340) [patch] After a blind transfer by the calling party the transferees peer cannot be dialed again within the same call

[Mark Michelson (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-16340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Michelson closed ASTERISK-16340.
-------------------------------------

    Resolution: Fixed

*dusts the cobwebs off this issue*

Well, it's been a while, but I believe that this issue has been resolved independently.

In the 1.8 branch, revisions  315644, 319529, and 328663 should resolve this issue. I have conducted my own tests and have found that the transfer scenarios provided by the original reporter no longer occur in version 1.8 of Asterisk. If you are still on Asterisk 1.4 or 1.6.2 you should also find this issue fixed as well, since the 1.8 revisions I listed were merged from those branches.

The final two revisions I listed were merged in May and July of 2011, after the final comments on this issue were made. They are similar to the patches uploaded here, but not quite the same. A similar patch has also been applied to app_queue. I am going to close this issue since I believe it to be fixed.

> [patch] After a blind transfer by the calling party the transferees peer cannot be dialed again within the same call
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-16340
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16340
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/General
>            Reporter: Ramon Peek
>            Severity: Minor
>         Attachments: 0001-Erase-the-already-dialed-interface-channel-datastore.patch, app_dial_allow_blind_xfer_back_to_originally_called_extension.patch, debug_log.tar.gz, fixRetransfering1.6.2.15.patch, fixRetransfering.patch
>
>
> 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)
> ****** STEPS TO REPRODUCE ******
> I use this small dialplan to test:
> ===================================
> exten = 400,1,Dial(Local/400 at local,15)
> exten = 401,1,Dial(Local/401 at local,15)
> exten = 402,1,Dial(Local/402 at local,15,g)
> exten = 402,n,Dial(Local/401 at local,15,g)
> exten = 402,n,Dial(Local/404 at local,15)
> exten = 403,1,Dial(Local/403 at local,15)
> [local]
> exten = _XXX,1,Dial(SIP/${EXTEN},14)
> THEN DO THE FOLLOWING:
> =======================
> 1) Call from peer 400 to 401 and answer the call at 401
> 2) On peer 400 blind transfer the call to peer 403 and answer the call at 403
> 3) On peer 401 blind transfer the call to peer 402, BUT DO NOT ANSWER and see what happens...
> Due to a fallback programmed into the dialplan, the call to peer 402 will return to peer 401 (return on noanswer).
> Asterisk however thinks the peer is already being dialed, but it really isn't.
> So this result in peer 401 not being dialed and the next priority being executed, which is the dialing of peer 404.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira