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.<div>
<br></div><div>The trick for not receiving events irrelevant to my session was issuing following at the beginning of my session:</div><div><br></div><div>filter unique-id <uuid>\n\n</div><div>filter channel-call-uuid <uuid>\n\n</div>
<div><br></div><div>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. </div>
<div><br></div><div>Moe<br><div><br><div class="gmail_quote">On Wed, Mar 23, 2011 at 1:41 PM, Dmitry Sytchev <span dir="ltr"><<a href="mailto:kbdfck@gmail.com">kbdfck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br><br>
I written wrapper around ESL.pm to implement executeSync which waits for CHANNEL_EXECUTE_COMPLETE while in async mode, works for now.<br>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?<br>
<br><div class="gmail_quote"><div><div></div><div class="h5">2011/3/23 Michael Collins <span dir="ltr"><<a href="mailto:msc@freeswitch.org" target="_blank">msc@freeswitch.org</a>></span><br></div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><div></div><div class="h5">
<br><br><div class="gmail_quote"><div>On Wed, Mar 23, 2011 at 6:48 AM, lakshmanan ganapathy <span dir="ltr"><<a href="mailto:lakindia89@gmail.com" target="_blank">lakindia89@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hi,<br>Eventlock is used to say "Whether to queue the commands or not".<br><br>Assume I'm giving playback and bridge command via outbound socket to freeswitch.<br><br>If eventlock is "true" then, first "playback will be executed" and then only the bridge will be executed.<br>
<br>If eventlock is "false", then order of execution is not guaranteed. <br><br>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.<br>
<br>This works well for me.<br><br></blockquote></div><div>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.</div>
<div><br></div><div><a href="http://wiki.freeswitch.org/wiki/Event_socket" target="_blank">http://wiki.freeswitch.org/wiki/Event_socket</a></div><div><br></div><font color="#888888"><div>-MC</div></font></div>
<br></div></div><div class="im">_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></div></blockquote></div><div><div></div><div class="h5"><br><br clear="all"><br>-- <br>Best regards,<br><br>Dmitry Sytchev,<br>IT Engineer<br>
</div></div><br>_______________________________________________<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div></div>