Summary:	ASTERISK-02437: Manager Redirect action does not function in certain conditions.
Reporter:	dw (dw)	Labels:
Date Opened:	2004-09-20 11:07:27	Date Closed:	2011-06-07 14:10:32
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Hello there, As per the e-mail contained in "additional information" (sent originally to asterisk-users), attempting to Redirect a channel which has not yet reached an application or a bridge fails. Basically, I can work around this by starting the MusicOnHold application on the channel while my manager service works out where the channel is supposed to be redirected to. If I just leave the channel hanging, I get a message indicating the call timed out in the destination context, even though the first priority of that context has not yet been executed. ****** ADDITIONAL INFORMATION ****** I am currently developing the ability to have a unified system/telephone login, with SIP phones paired to a computer. When a user logs into a computer, a notification is sent to an external service program which connects to Asterisk through the manager API. Besides that, the service program tracks user status on the computer, and triggers actions depending on various conditions. One of those actions is to play a recording to a caller depending on what the user is currently doing, eg. on the phone, not at work, and so on. My setup is similar to this:  [local_extensions]  exten = _XXX,1,Macro(internal_call,${EXTEN})  [macro-internal_call]  exten = s,1,Answer  exten = s,2,SetVar(destination_number=${ARG1})  exten = s,3,UserEvent(InternalOriginate) My service program connects to the manager API and waits for InternalOriginate events. When it sees one, it reads the destination number from the channel variable via the Getvar action, then looks at it's session information to determine whether the user is logged in, and if so, his current SIP channel, and so on. Now, for the simple case of the user not being available and an announcement needs played, I have another context:  [play_response]  exten = s,1,Playback(/etc/asterisk/sounds/response-${RESPONSE})  exten = s,2,Hangup My service program first uses Setvar to set RESPONSE to the name of a recording, then Redirect to transfer the channel to that context. This is where it fails. I see no "Newexten" events indicating the beginning of playback, and the channel (as seen from output of the Status action) does not appear to change state. The only thing that follows is a hang up at timeout. [and a message on the Asterisk console: 2004-09-20 16:30:16 WARNING[1104239536]: pbx.c:1933 ast_pbx_run: Timeout, but no rule 't' in context 'play_response']
Comments:	By: Mark Spencer (markster) 2004-09-21 07:50:24 Can you describe what you mean by a channel which hasn't reached an application or  a bridge? By: dw (dw) 2004-09-21 09:55:29 I don't a lot about the Asterisk internals yet, but I assume there is a period at the start of a call before the audio channel is connected during which only a Ringing tone/etc. is audible on the line. That is what I was referring to. Basically, the Redirect works for me if I start MusicOnHold after answering the channel and firing my event, but if I simply do Answer, Ringing, UserEvent(IncomingCall), the redirect returns successfully but soon after I get a message on the console telling me "Timeout, but no rule 't' in context '...'". Where context is the context I wanted the call transferred to. Simple example / pseudo code: dialplan:   [zapata_destination_for_incoming_calls]   exten = s,1,Answer   exten = s,2,Ringing   exten = s,3,UserEvent(IncomingCall) service:   on UserEvent IncomingCall:      destination = determine_destination()      manager.Redirect(event.Channel, destination) Is there perhaps some inner loop that runs when audio data is being tossed that handles the redirects, which might not yet be started up at this stage in the call? *shrugs* :( I basically want incoming channels to cause an event then hang until my service deals with them. Thanks, David. By: dw (dw) 2004-09-21 10:20:42 Sorry, in addition I notice that the channel sits in priority 0, which seems strange to me. Possibly indicating some processing loop isn't running yet? *CLI> show channels SIP/102-7190        Channel  (Context    Extension    Pri )   State Appl.         Data   SIP/102-7190  (queue      s            0   )      Up (None)        (None) By: dw (dw) 2004-10-05 18:26:19 Any ideas or movement on this? I've sunk myself a little deeper into Asterisk than I was when I reported this, so even if you could give me a hint in the general direction of what it might be, I will try and sort it out myself. Closely related to this bug is work on a "pbx_config_mgr" module which allows dialplan configuration at runtime via the manager API. The work is 95% complete, with the exception of "ContextCreate" and "ContextDestroy" actions. The module is also only 42% of the size of the existing pbx_config.c. Between this bug and that work (which I hope to post here when it is complete), I have an elegant and flexible system for runtime reconfiguration and call control without resorting to "Action: command" kludges. I'll stop my whining now, basically this is a beg for a little help in return for a great new feature for Asterisk. :) Thanks again for your time, David. By: twisted (twisted) 2004-10-27 16:37:16 Is this still an issue?  Is this even an issue at all? By: dw (dw) 2004-10-28 05:09:47 Yes. Yes. By: ipdeman (ipdeman) 2004-10-28 08:49:27 I hope this bug also applies to bugnote 0002671. Although I patched chan_zap.c, adding a avariable to confirm fax detection and using that variable to redirect to  a fax extension in the dialplan, I feal this bugnote may fix the problem. Still my work around was not actually a fix but a workaround, I did not post it here. By: Mark Spencer (markster) 2004-10-28 09:22:29 We need to catch up on IRC again. By: Brian West (bkw918) 2004-11-08 09:30:23.000-0600 Find someone to look at your bug please we can't have these things just sit here. bkw By: dw (dw) 2004-11-09 18:21:32.000-0600 Brian, This bug still exists, regardless of whether someone is working on it or not, issue trackers are not designed to be esthetically pleasing. Mark, If you can spare the time that would be excellent. I'll appear on IRC over this weekend as much as I can, if that is at all suitable for you. Thanks again both of you. By: Mark Spencer (markster) 2004-11-16 23:59:50.000-0600 Just find me on IRC.  I'm there qutie a bit of the time, and that's the only way we're going to get anywhere with this. By: twisted (twisted) 2004-12-01 01:10:47.000-0600 dw, were you able to speak with markster regarding this on IRC?  If so, what was the outcome? By: dw (dw) 2004-12-01 06:28:56.000-0600 Hey there, Unfortunately I haven't had the time to get in contact yet. The VoIP software I've been developing for my employer has also been suspended until at least January, so I have no immediate need for a fix just now. How about we close this report, and I'll reopen one in January/February if the problem still persists with CVS at that point? I'm fairly sure the problem is still there, but you seem to have a policy of closing bugs that aren't affecting anybody, which I'm happy enough with. It's worth noting before closing that other people are monitoring this bug - it is possible that one of them could get in contact with Mark to set up a debugging session. ***** PEEPS MONITORING BUG: WE NEED YOUR HELP! :) ***** Thanks, David. By: Olle Johansson (oej) 2004-12-13 02:08:11.000-0600 Closing per submitter's request. Please reopen when you are ready to start working on this again.