Summary:	ASTERISK-15890: ChannelRedirect() fails to properly redirect some of the time
Reporter:	Bryan Vyhmeister (brycv)	Labels:
Date Opened:	2010-03-29 14:47:56	Date Closed:	2011-06-07 14:00:52
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/app_chanspy
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: Bryan Vyhmeister (brycv) 2010-03-29 21:21:34 This was supposed to be filed under [Asterisk] Applications/app_channelredirect. This was selected initially but was somehow changed before I filed the report. If that can be changed, great. If not, I will file a new bug report. By: Bryan Vyhmeister (brycv) 2010-03-30 08:19:58 Please close this bug as it was incorrectly filed. The correct bug report is 0017117. Thank you.