Summary:	ASTERISK-15792: Dialplan continues execution after transfer
Reporter:	Mat Murdock (mmurdock)	Labels:
Date Opened:	2010-03-11 13:33:34.000-0600	Date Closed:	2011-08-16 12:39:09
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	PBX/General
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-18275 DTMF blind transfer continues in dialplan after transfer.
Environment:		Attachments:	( 0) fix_atxfer_parking.diff ( 1) fix_atxfer_parking2.diff
Description:	A Call B B Answers A does a dtmf attended transfer to 700 B is transfered A hears parking slot and with the dialplan shown below hears weasels. A should not hear weasels.  Dialplan execution should of ended after the dial application ran. ****** ADDITIONAL INFORMATION ****** Simplified Dialplan INTERNAL_DIAL_OPTIONS = KkTtWw exten => _1134,1,Answer() exten => _1134,n,Dial(SIP/${EXTEN},${RINGTIMER},${INTERNAL_DIAL_OPTIONS}) exten => _1134,n,Playback(tt-weasels) exten => _1134,n,Hangup() ****Asterisk Manager Output**** 1123 Calls 1134 == Using SIP RTP CoS mark 5    -- Executing [1134@from_internal:1] Answer("SIP/1123-00000024", "") in new stack    -- Executing [1134@from_internal:2] Dial("SIP/1123-00000024", "SIP/1134,20,KkTtWw") in new stack  == Using SIP RTP CoS mark 5  == Extension Changed 1134[from_internal] new state Ringing for Notify User 1134  == Extension Changed 1134[from_internal] new state Ringing for Notify User 1197    -- Called 1134    -- SIP/1134-00000025 is ringing    -- SIP/1134-00000025 is ringing    -- SIP/1134-00000025 is ringing  == Extension Changed 1134[from_internal] new state InUse for Notify User 1134  == Extension Changed 1134[from_internal] new state InUse for Notify User 1197    -- SIP/1134-00000025 answered SIP/1123-00000024    -- Started music on hold, class 'default', on SIP/1134-00000025    -- <SIP/1123-00000024> Playing 'pbx-transfer.gsm' (language 'en')    -- Stopped music on hold on SIP/1134-00000025    -- Started music on hold, class 'default', on SIP/1134-00000025  == Parked SIP/1134-00000025 on 701 (lot default). Will timeout back to extension [from_internal] , 1 in 20 seconds    -- Added extension '701' priority 1 to parkedcalls (0xb6b94a38)  == Extension Changed 701[from_internal] new state InUse for Notify User 1134  == Extension Changed 701[from_internal] new state InUse for Notify User 1197    -- <SIP/1123-00000024> Playing 'digits/7.gsm' (language 'en')    -- <SIP/1123-00000024> Playing 'digits/0.gsm' (language 'en')    -- <SIP/1123-00000024> Playing 'digits/1.gsm' (language 'en')    -- Executing [1134@from_internal:3] Playback("SIP/1123-00000024", "tt-weasels") in new stack    -- <SIP/1123-00000024> Playing 'tt-weasels.gsm' (language 'en')
Comments:	By: Leif Madsen (lmadsen) 2010-03-18 14:50:59 This does appear to be a bug, but we've discussed this can only be fixed in trunk, as it may be one of those "bugs" that is a "feature" for some people. If we make this change to all existing branches, we may break some other peoples dialplans who are expecting this to work. The patch will be available here for anyone who needs it on existing branches, but the fix will only be committed to trunk, with information about the changes being documented in the UPGRADE.txt file. By: Mat Murdock (mmurdock) 2010-03-18 17:00:28 Which versions will a patch be created for and will it be maintained?  Will it be part of 1.8? By: rsw686 (rsw686) 2010-03-19 07:32:31 This is related to 0016856. The behavior was changed at the end of the 1.4 branch and looks to exist in 1.6.0, 1.6.1, and 1.6.2. If we keep the behavior functionality is broken for those migration from 1.4. If we change it back it breaks functionality for those running 1.6.x. Can we just add a setting to turn this on or off. This would solve the problem for everyone. By: Leif Madsen (lmadsen) 2010-03-24 09:37:12 I'll discuss with the developers to see what their anticipated plan of attack would be after the new information provided. By: Mat Murdock (mmurdock) 2010-04-13 13:34:26 Any word on this issue? By: Mat Murdock (mmurdock) 2010-09-14 16:09:26 So, did a fix for this make it into 1.8?  It was mentioned the fix would be put into trunk. By: Leif Madsen (lmadsen) 2010-09-16 09:27:18 No further work has been done on this issue yet. When work is done on this issue you will see updates here. By: Terry Wilson (twilson) 2011-08-10 16:24:14.594-0500 This is clearly a bug. builtin_atxfer should return either AST_FEATURE_RETURN_SUCCESS or -1. It was returning whatever parkcall_helper returned, which returns 0 for success. 0 does not equal AST_FEATURE_RETURN_SUCCESS. Feel free to test the attached patch (for 1.8). By: Terry Wilson (twilson) 2011-08-10 16:50:06.025-0500 fix_atxfer_parking2.diff actually contains the fix for both blind and attended transfers since both were broken in the same way. rmudgett is working on a more comprehensive fix for parking in general, so I am not committing this since it will cause a needless conflict in his branch. He will include it in his commit. By: Richard Mudgett (rmudgett) 2011-08-15 12:53:40.158-0500 There are currently a bunch of issues reported against call parking.  These issues are listed with a brief description in the patch I have up on reviewboard[1] to resolve them and other parking issues I found.  A team branch[2] from the v1.8 branch is also available to checkout until the patch is merged into the v1.8 and newer branches. The Asterisk Development Team would like some testers to check out the patch and to report on this thread your findings.  We would like to compile some real world test scenarios for a wiki page to prevent call parking from getting this badly broken in the future. Thank you Richard [1] https://reviewboard.asterisk.org/r/1358/ [2] http://svn.asterisk.org/svn/asterisk/team/rmudgett/parking By: Richard Mudgett (rmudgett) 2011-08-16 12:39:09.830-0500 Fix committed see subversion commits tab.