[Freeswitch-users] Event-lock, sync/async on outbound ESL and execute() tagging question

[Mohammad Amin]

I have hash table which keeps track of api & dp applications I have executed to process the events & responses I get from FS, based on that I control the flow of execution in my application.

For instance for the 'read' application my server returns the result  variable as soon as It receives CHANNEL_EXECUTE_COMPLETE with the 'application: read' in it's content.

The fired events are very self explanatory it has all the info you need to control the execution flow. If you watch for the 'application' in the content of CHANNEL_EXECUTE_COMPLETE and you keep track of what applications you have executed so far you can map them very easily.

Moe

On Mar 24, 2011, at 11:11 AM, Dmitry Sytchev wrote:

> I don't get any irrelevant channel events, it's my events or my child channel events.
> I want to distinguish events from previously launched execute() commands in my event loop, like job id in bgapi. These events can be from my own original channel as well, so uuid filter doesn't help me.
> 
> 
> 2011/3/24 Moe Navid <manavid at gmail.com>
> I use outbound socket for bridging, I also do my accounting from there too, As soon as I get the CHANNEL_ANSWER event with the direction:outbound (in content) I defer a new process and create a timer which does 6 seconds billing increments.
> 
> The trick for not receiving events irrelevant to my session was issuing following at the beginning of my session:
> 
> filter unique-id <uuid>\n\n
> filter channel-call-uuid <uuid>\n\n
> 
> I wrote my server in Ruby, I'm using EventMachine for TCP handling and Ruby Fibers to write my apps synchronous fashion while talking to FreeSWITCH in async mode. Whenever I need to simulate the blocking mode and pause the execution at some point (with Fibers) I just start listening for the event that has do be received which indicates the job is done, in case of bridge, I enqueue the CHANNEL_HANGUP_COMPLETE and resume my app as soon as I receive it. 
> 
> Moe
> 
> 
> On Wed, Mar 23, 2011 at 1:41 PM, Dmitry Sytchev <kbdfck at gmail.com> wrote:
> I understand this. I use outbound async full ESL mode, launching socket app from dialplan, because in sync mode I have some problems with bridge app and I need to catch parent channel hangup and server disconnection.
> 
> I written wrapper around ESL.pm to implement executeSync which waits for CHANNEL_EXECUTE_COMPLETE while in async mode, works for now.
> But of course it is not the best way, because of possible error when 'execute' is used before my 'executeSync' by mistake and without proper event handling so that CHANNEL_EXECUTE_COMPLETE from previous app is catched by my wrapper and it returns prematurely. This is why I want to have some tag I can mark execute call to filter its events later... Maybe there is better way?
> 
> 2011/3/23 Michael Collins <msc at freeswitch.org>
> 
> 
> On Wed, Mar 23, 2011 at 6:48 AM, lakshmanan ganapathy <lakindia89 at gmail.com> wrote:
> Hi,
> Eventlock is used to say "Whether to queue the commands or not".
> 
> Assume I'm giving playback and bridge command via outbound socket to freeswitch.
> 
> If eventlock is "true" then, first "playback will be executed" and then only the bridge will be executed.
> 
> If eventlock is "false", then order of execution is not guaranteed. 
> 
> I'm also using Outbound event socket. I'll run it in async mode. After each execute() statement, if I need the output for that event, I will wait for the event and then only I'll proceed. If I don't need event, ( playback ), I just do the other operations.
> 
> This works well for me.
> 
> Be sure that you are using the terms "inbound" and "outbound" event socket correctly. It's inbound or outbound from the perspective of FreeSWITCH, not from the perspective of your script. An easy rule of thumb is this: if you use the 'socket' application in your dialplan then you are using "outbound event socket" because FS has to make an outbound connection to your script.
> 
> http://wiki.freeswitch.org/wiki/Event_socket
> 
> -MC
> 
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
> 
> 
> 
> 
> -- 
> Best regards,
> 
> Dmitry Sytchev,
> IT Engineer
> 
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
> 
> 
> 
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
> 
> 
> 
> 
> -- 
> Best regards,
> 
> Dmitry Sytchev,
> IT Engineer
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110324/d3343848/attachment-0001.html