Summary:	ASTERISK-15894: ChannelRedirect() fails to redirect
Reporter:	Bryan Vyhmeister (brycv)	Labels:
Date Opened:	2010-03-30 08:19:13	Date Closed:	2011-06-07 14:00:49
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_channelredirect
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I am using a very simple extensions.conf with all of the defaults except for enabling a dynamic feature which shows up in features.conf as: [applicationmap] dynconf => *3,caller,Macro,dynamic-conf This feature calls the items in the macro and context below. [dynamic-conf] exten => _X.,1,MeetMe(${EXTEN},d) [macro-dynamic-conf] exten => s,1,Answer exten => s,n,ChannelRedirect(${BRIDGEPEER},dynamic-conf,1000,1) exten => s,n,SoftHangup(${CHANNEL}) The goal is for a call to come in and be answered by a customer service representative (CSR) using a SIP or IAX2 phone. The CSR uses *3 or another feature code that calls the dynconf dynamic feature. On execution, ChannelRedirect only sends the caller through to the MeetMe conference some of the time. Replacing the MeetMe command with MusicOnHold or Playback does not change the outcome. I find that on a 1.83GHz Dual Core system it fails between 25-50% of the time. On a much faster Octo Core system it fails 90% or more of the time. The debug output from it working or not working is the same. Here is the case where it does not work:    -- Executing [s@macro-dynamic-conf:1] Answer("SIP/7600-00000006", "") in new stack    -- Executing [s@macro-dynamic-conf:2] ChannelRedirect("SIP/7600-00000006", "IAX2/provider-982,dynamic-conf,1000,1") in new stack    -- Executing [s@macro-dynamic-conf:3] SoftHangup("SIP/7600-00000006", "SIP/7600-00000006") in new stack [Mar 29 15:19:52] WARNING[9015]: app_softhangup.c:114 softhangup_exec: Soft hanging SIP/7600-00000006 up.  == Spawn extension (dynamic-conf, 1000, 1) exited non-zero on 'IAX2/provider-982'    -- Executing [1000@dynamic-conf:1] MeetMe("IAX2/provider-982", "1000,d") in new stack    -- Created MeetMe conference 1023 for conference '1000'    -- <IAX2/provider-982> Playing 'conf-onlyperson.ulaw' (language 'en')    -- Hungup 'DAHDI/pseudo-833173156'  == Spawn extension (dynamic-conf, 1000, 1) exited non-zero on 'IAX2/provider-982'    -- Hungup 'IAX2/provider-982' This is a case where it does work correctly. The final three lines are delayed until I intentionally hangup the call where they happen immediately on a failure.    -- Executing [s@macro-dynamic-conf:1] Answer("SIP/7600-00000008", "") in new stack    -- Executing [s@macro-dynamic-conf:2] ChannelRedirect("SIP/7600-00000008", "IAX2/provider-426,dynamic-conf,1000,1") in new stack    -- Executing [s@macro-dynamic-conf:3] SoftHangup("SIP/7600-00000008", "SIP/7600-00000008") in new stack [Mar 29 15:33:34] WARNING[9054]: app_softhangup.c:114 softhangup_exec: Soft hanging SIP/7600-00000008 up.  == Spawn extension (dynamic-conf, 1000, 1) exited non-zero on 'IAX2/provider-426'    -- Executing [1000@dynamic-conf:1] MeetMe("IAX2/provider-426", "1000,d") in new stack    -- Created MeetMe conference 1023 for conference '1000'    -- <IAX2/provider-426> Playing 'conf-onlyperson.ulaw' (language 'en')    -- Hungup 'DAHDI/pseudo-311765546'  == Spawn extension (dynamic-conf, 1000, 1) exited non-zero on 'IAX2/provider-426'    -- Hungup 'IAX2/provider-426' Based on my tests, the faster the machine, the more often it fails. I have not been able to find any differences in the debug between a success and failure. I am glad to provide any additional information if necessary. ****** ADDITIONAL INFORMATION ****** This has been tested on two different systems. One is an HP DL360 G6 with Octo Cores and the other is a 1.83GHz Core Duo system. Both systems are running Asterisk-1.6.2.6 on CentOS 5.4 i386.
Comments:	By: Leif Madsen (lmadsen) 2010-03-31 09:37:46 I'm not sure if there is anything that can be done here. Per the features.conf file: ; IMPORTANT NOTE: The applicationmap is not intended to be used for all Asterisk ;   applications. When applications are used in extensions.conf, they are executed ;   by the PBX core. In this case, these applications are executed outside of the ;   PBX core, so it does *not* make sense to use any application which has any ;   concept of dialplan flow. Examples of this would be things like Macro, Goto, ;   Background, WaitExten, and many more. By: Bryan Vyhmeister (brycv) 2010-03-31 13:21:49 So what you're saying is that essentially only single commands are supported such as Transfer, Playback, etc.? There has to be a way for this to work correctly in order to be able to send calls somewhere else using DTMF. By: leff (leff) 2010-04-02 07:20:18 The same problem with 1.4.30. As a workaround try to use the feature at peer site and ChannelRedirect(${CHANNEL}... By: Leif Madsen (lmadsen) 2010-04-15 10:20:00 Based on the information provided, this does not look like a bug.