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

[Moe Navid]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110324/f7cbd7c9/attachment-0001.html