Summary:	ASTERISK-25641: bridge: GOTO_ON_BLINDXFR doesn't work on transfer initiated channel
Reporter:	Dmitry Melekhov (slesru)	Labels:
Date Opened:	2015-12-22 01:58:14.000-0600	Date Closed:	2015-12-28 09:46:36.000-0600
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Core/Bridging/bridge_basic
Versions:	13.6.0	Frequency of Occurrence
Related Issues:
Environment:	Centos 7 x86-64	Attachments:	( 0) blind-ast11 ( 1) blind-ast13 ( 2) jira_asterisk_25641_v13.patch
Description:	Hello! I'm trying to get n-way call on asterisk according to instructions here http://habrahabr.ru/sandbox/52259/ although it is in russian, dialplan is quite obvious, and it works in asterisk 11, but doesn't work in asterisk 13 because GOTO_ON_BLINDXFR macro is executed only for one channel, namely another side of transfer, but no for channel initiated transfer. As I know, this change is not documented, so I assume this is bug. I'll attach console output for asterisk 11 and asterisk 13. Thank you!
Comments:	By: Asterisk Team (asteriskteam) 2015-12-22 01:58:16.897-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Dmitry Melekhov (slesru) 2015-12-22 01:58:55.396-0600 asterisk 11 works By: Dmitry Melekhov (slesru) 2015-12-22 01:59:18.690-0600 asterisk 13 doesn't work By: Joshua C. Colp (jcolp) 2015-12-22 06:10:04.347-0600 Why don't you use the new multi-party bridge ability in 13? If you perform a DTMF based attended transfer hitting *3 (this is configurable in features.conf) will turn it into a multi-party conference. Would this accomplish what you are wanting to do? By: Dmitry Melekhov (slesru) 2015-12-22 06:43:02.041-0600 Really, for some reason, attended transfer doesn't work for me at all,  I always get: bridge_basic.c:3283 feature_attended_transfer: Unable to acquire target extension for attended transfer, I tried this from ekiga and from yealink sip phone - result is the same. This is, definitely, different problem, but if attended transfer works, it can be solution. Blind transfer works just fine though, so I'd like to have the same behavior for GOTO_ON_BLINDXFR in asterisk 13 as in 11. Thank you! By: Dmitry Melekhov (slesru) 2015-12-22 22:38:53.671-0600 Hello! By the way, I solved my problem with attended transfer, it was just my mistyping in  TRANSFER_CONTEXT, found only today, yesterday everything looked fine for me ;-) , so it works as expected, Thank you! By: Dmitry Melekhov (slesru) 2015-12-23 10:50:34.735-0600 Could you, please, explain why it is closed as not a bug while this change in behavior is not documented? Thank you! By: Asterisk Team (asteriskteam) 2015-12-23 10:50:35.159-0600 This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable. By: Richard Mudgett (rmudgett) 2015-12-23 11:00:40.225-0600 I closed it based upon *your* comment above saying it now works as expected after fixing a typographical error. By: Dmitry Melekhov (slesru) 2015-12-23 12:18:24.459-0600 Richard, then you did a mistake, just because I never said it works as expected. I commented that I got attended transfer working , which I tried by Joshua suggestion, but this is just another way to get n-way conference. Original problem- GOTO_ON_BLINDXFR doesn't work on transfer initiated channel - still exists. Please, fix it, or , if this behavior change it transition from asterisk 11 to 13 is by design, confirm this change. Thank you! By: Matt Jordan (mjordan) 2015-12-23 15:37:37.294-0600 [~slesru]: Which channel initiated the blind transfer in your log snippet, the SIP channel or the DAHDI channel? And where was the target of the blind transfer supposed to be sent to? {{GOTO_ON_BLINDXFR}} should transfer the initiator of the transfer to the specified extension (it wouldn't make any sense to transfer the transfer target, as they just got transferred wherever the user sent them). In your log snippet, the DAHDI channel is getting tossed into the target of the {{GOTO_ON_BLINDXFR}} variable. It looks as if it should have been the SIP channel, but I'd like to confirm that before this is accepted. By: Matt Jordan (mjordan) 2015-12-23 16:09:17.849-0600 Hm. This may just be a case of using the wrong delimeter: {{__GOTO_ON_BLINDXFR=fromtransfer^0^1}} Try: {{__GOTO_ON_BLINDXFR=fromtransfer,0,1}} By: Richard Mudgett (rmudgett) 2015-12-23 18:00:36.528-0600 [^jira_asterisk_25641_v13.patch] - This should fix the GOTO_ON_BLINDXFR issue.  We were calling a function with invalid parameters which the function checked and just simply returned.  If assertions were enabled you would have had an assertion triggered. Please test the patch.  Thanks. [~mjordan] The delimiter could be either '\^' or ',' since the first thing the function does is convert the '\^' delimiters to commas. By: Dmitry Melekhov (slesru) 2015-12-23 22:48:54.540-0600 Hello! Now, with applied patch, GOTO_ON_BLINDXFR macro is executed for both channels:    -- Executing [0@fromtransfer:1] NoOp("DAHDI/i1/6000-8", "") in new stack    -- Executing [0@fromtransfer:2] Gosub("DAHDI/i1/6000-8", "dynamic-nway,5082,1") in new stack ...    -- Executing [0@fromtransfer:1] NoOp("SIP/5082-00000008", "") in new stack    -- Started music on hold, class 'none', on channel 'DAHDI/i1/6000-8'    -- Executing [0@fromtransfer:2] Gosub("SIP/5082-00000008", "dynamic-nway,5082,1") in new stack Thank you very much! And thank you for hint about attended transfer feature in asterisk 13! By: Matt Jordan (mjordan) 2015-12-24 07:50:16.530-0600 [~rmudgett]: Thanks, missed that in the function :-P By: Richard Mudgett (rmudgett) 2015-12-24 10:17:32.618-0600 [~slesru] FYI - GOTO_ON_BLINDXFR *only* applies to the transferring channel.  When you are doing the blind transfer you just happen to be transferring the target channel to the same place. By: Dmitry Melekhov (slesru) 2015-12-24 12:21:46.109-0600 Thank you for clarification.