Summary:	ASTERISK-15650: [regression] Blind transfers initiated from calling party aren't disconncted
Reporter:	rsw686 (rsw686)	Labels:
Date Opened:	2010-02-17 14:08:04.000-0600	Date Closed:	2011-07-27 13:40:02
Priority:	Major	Regression?	Yes
Status:	Closed/Complete	Components:	Applications/app_transfer
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Employee A calls a customer and talks for a few minutes. The customer asks to talk to someone in another depart. Employee A does a blind transfer with ## to Employee B. The result is Employee B is connected to the customer. However Employee A receives the all circuits are busy now message. What should happen is Employee A is disconnected. I was originally using Asterisk 1.6.1.4, but have tested Asterisk 1.6.1.14 with the same result.
Comments:	By: Leif Madsen (lmadsen) 2010-02-17 14:13:25.000-0600 Please test the latest release candidate as many transfer related issues were resolved in that release candidate. By: rsw686 (rsw686) 2010-02-17 14:37:21.000-0600 Just tested 1.6.1.15-rc2 and I am still having this issue. The issue only occurs when transferring a call you initiated. If you receive a call and transfer everything works as expected. By: rsw686 (rsw686) 2010-02-23 22:52:17.000-0600 I'm not sure if this is an Asterisk or FreePBX issue. FreePBX 2.6.0.1 has a macro-dialout-trunk which contains exten => s,n,Dial(${OUT_${DIAL_TRUNK}}/${OUTNUM},300,${DIAL_TRUNK_OPTIONS}) exten => s,n,Goto(s-${DIALSTATUS},1) For calls when you hangup it looks like Dial falls through to the end of the macro and runs exten => h,1,Macro(hangupcall,) However for transfers it returns the status ANSWER which runs exten => _s-.,1,GotoIf($["x${OUTFAIL_${ARG1}}" = "x"]?noreport) exten => _s-.,n,AGI(${OUTFAIL_${ARG1}}) exten => _s-.,n(noreport),Noop(TRUNK Dial failed due to ${DIALSTATUS} - failing through to other trunks) I added in a cause for ANSWER, which solved the issue. exten => s-ANSWER,1,Noop(Dial completed with trunk reporting ANSWER - hanging up) exten => s-ANSWER,n,Macro(hangupcall,) I posted this as a bug to FreePBX, before I found out the above, and was told that they tested my scenario on Asterisk 1.4 and it was working. The ended up closing the bug report. I am wondering if the Dial behavior changed between Asterisk 1.4 and 1.6.1 for this case? Should I be making another bug report to FreePBX? By: Francesco Romano (francesco_r) 2010-02-24 04:29:23.000-0600 This bug is one year old. I have reported the same issue last year for asterisk 1.4 but with parked calls and was partially solved (today problem still present on outgoing calls): ASTERISK-13653 (note #109772) P.S.: i use also FreePBX but till asterisk 1.4.21 this problem was absent so i think is an asterisk regression, and not a Freepbx bug By: Leif Madsen (lmadsen) 2010-02-24 09:58:22.000-0600 If functionality changed between versions of Asterisk, then this is certainly a regression. I will mark this as such. By: Leif Madsen (lmadsen) 2010-02-24 09:59:37.000-0600 If someone could provide an example of the dialplan and configuration along with the steps to reproduce this issue then that would be useful. That way it can be tested against 1.4.21 to see what happened then (presumably the right way) and then try a newer version to see the regression. Console output of the two issues being tested on the versions would certainly be useful as well if someone wanted to go that far. By: rsw686 (rsw686) 2010-02-25 22:42:31.000-0600 I don't have a good example dialplan as the dialplan generated by FreePBX is huge with around 200 extensions. Let me see if I can reproduce it with the dialplan shown on 0014555. The main issue is after the transfer Dial allows execution to proceed with the status set to ANSWER. If it helps the FreePBX ticket is http://www.freepbx.org/trac/ticket/4053 and workaround http://www.freepbx.org/trac/changeset/8930. By: rsw686 (rsw686) 2010-03-16 12:40:23 I can reproduce this with the below basic dialplan on 1.6.1.18. 8532 calls 8678 8532 then presses ## 8688 (## assigned as the blind transfer code) 8678 is connected to 8688 8532 starts hearing busy tones as Asterisk didn't hangup the call [default] exten => 8678,1,Answer exten => 8678,n,Dial(SIP/8678,,Ttr) exten => 8678,n,Busy exten => 8688,1,Answer exten => 8688,n,Dial(SIP/8688,,Ttr) exten => 8688,n,Busy exten => 8532,1,Answer exten => 8532,n,Dial(SIP/8532,,Ttr) exten => 8532,n,Busy Console output  == Using SIP RTP CoS mark 5    -- Executing [8678@default:1] Answer("SIP/8532-0000001c", "") in new stack    -- Executing [8678@default:2] Dial("SIP/8532-0000001c", "SIP/8678,,Ttr") in new stack  == Using SIP RTP CoS mark 5    -- Called 8678    -- SIP/8678-0000001d is ringing    -- SIP/8678-0000001d answered SIP/8532-0000001c    -- Started music on hold, class 'default', on SIP/8678-0000001d    -- <SIP/8532-0000001c> Playing 'pbx-transfer.gsm' (language 'en')    -- Stopped music on hold on SIP/8678-0000001d [Mar 16 13:37:51] DEBUG[28366]: features.c:1248 builtin_blindtransfer: transferer=SIP/8532-0000001c; transferee=SIP/8678-0000001d; lastapp=Dial; lastdata=SIP/8678,,Ttr; chan=SIP/8532-0000001c; dstchan=SIP/8678-0000001d [Mar 16 13:37:51] DEBUG[28366]: features.c:1251 builtin_blindtransfer: TRANSFEREE; lastapp=; lastdata=, chan=SIP/8678-0000001d; dstchan= [Mar 16 13:37:51] DEBUG[28366]: features.c:1253 builtin_blindtransfer: transferer_real_context=default; xferto=8688    -- Transferring SIP/8678-0000001d to '8688' (context default) priority 1    -- Executing [8678@default:3] Busy("SIP/8532-0000001c", "") in new stack    -- Executing [8688@default:1] Answer("SIP/8678-0000001d", "") in new stack    -- Executing [8688@default:2] Dial("SIP/8678-0000001d", "SIP/8688,,Ttr") in new stack  == Using SIP RTP CoS mark 5    -- Called 8688    -- SIP/8688-0000001e is ringing    -- SIP/8688-0000001e answered SIP/8678-0000001d  == Spawn extension (default, 8678, 3) exited non-zero on 'SIP/8532-0000001c'  == Spawn extension (default, 8688, 2) exited non-zero on 'SIP/8678-0000001d' By: Russell Bryant (russell) 2011-07-27 13:39:55.511-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!