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

[Dmitry Sytchev]

Application name can be the same for multiple execute() calls, so we need to
hash by name+params+uuid+something else, but single user- or autogenerated
tag field in request/response will be enough to track application execution
:)

Anyway, thanks to all for your ideas! I have similiar working solution, but
I thought if it can be done in some better way.

2011/3/24 Mohammad Amin <manavid at gmail.com>

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