Thanks Anthony,<br><br>I dropped the ball on this bigtime. I posted my question and somehow the messages didnt thread properly in my list and didn't see any responses until now.<br><br>I'll try your suggestions, it sounds like exactly what I was looking for. Unfortunately we just released our product with FreeSWITCH (alpha) support so it will have be included in a future update.<br>
<br>For this version, if the Saflet (event handler app) doesn't hang up the call and the caller remains on the line, in some cases the call remains in park indefinitely. I see this as more of an annoyance than a major issue but definitely something we want to address quickly.<br>
<br>In case you were interested the download site is <a href="http://www.safisystems.com/downloads">http://www.safisystems.com/downloads</a><br><br>We're still lacking somewhat in the documentation department but the existing screencasts and walkthroughs we have apply to both FreeSWITCH and Asterisk.<br>
<br>Thanks,<br>Zac<br>
<br><div class="gmail_quote">On Tue, Jan 11, 2011 at 2:45 PM, Anthony Minessale <span dir="ltr"><<a href="mailto:anthony.minessale@gmail.com" target="_blank">anthony.minessale@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What condition would you want to use to have the park terminate?<br>
<br>
Once you app is controlling the session, it would be up to you to<br>
enforce when it hangs up from the FS side.<br>
<br>
Based on what you describe the only issue could be when your remote<br>
application either misses the event or is restarted while calls are up<br>
so what I can suggest is this:<br>
<br>
in your C app, you could wait there for some timeout period just<br>
calling switch_ivr_sleep for 1 second up to 10 tries to wait a total<br>
of 10 seconds.<br>
<br>
If your app gets the event it can then transfer it to park using<br>
uuid_transfer, this would break the sleep loop and you could do<br>
something at the end of the loop like:<br>
<br>
if (switch_channel_ready(channel)) {<br>
switch_channel_hangup(channel, SWITCH_CAUSE_DESTINATION_OUT_OF_ORDER);<br>
}<br>
<br>
so when it was already hung or being transfered that could would not<br>
execute but if your loop ended from waiting too long and it was still<br>
active it would hangup.<br>
<br>
you could do something similar with just dp logic if you used park_timeout of 10<br>
then in your event handler app, use uuid_setvar to unset park_timeout,<br>
then uuid_transfer it back to park now with now timeout<br>
<br>
uuid_transfer <uuid> set:park_timeout=,park inline<br>
<br>
You should come and present this at ClueCon if you have it done in time.<br>
<div><br>
<br>
<br>
On Mon, Jan 10, 2011 at 4:03 PM, Zac Wolfe <<a href="mailto:zacw@safisystems.com" target="_blank">zacw@safisystems.com</a>> wrote:<br>
</div><div><div></div><div>> Hi guys,<br>
><br>
> First some good news: we're finally close to releasing our free IVR<br>
> Development platform SafiServer/SafiWorkshop (<a href="http://www.safisystems.com" target="_blank">www.safisystems.com</a>) with<br>
> FreeSWITCH support! It's happening much later than we originally anticipated<br>
> as we've been unexpectedly busy with contracting opportunities but I think<br>
> it will be worth the wait. Currently everything is working fine with one<br>
> minor exception: if the user-created script (we call them Saflets) doesn't<br>
> explicitly hang up the call, the call will remain parked until the caller<br>
> hangs up. Some details:<br>
><br>
> In Asterisk we invoke our server-side scripting applications via the<br>
> extensions.conf using the following syntax:<br>
><br>
> exten =<br>
> 1111,1,Agi(agi://<a href="http://192.168.0.10:3573/safletEngine.agi?saflet=project1/callflow1" target="_blank">192.168.0.10:3573/safletEngine.agi?saflet=project1/callflow1</a>)<br>
><br>
> Here '192.168.0.10' is the IP address of the SafiServer and<br>
> project1/callflow1 identifies the Saflet to be executed. Asterisk creates a<br>
> socket connection to the SafiServer and, once the socket is disconnected,<br>
> the call proceeds to the next entry in the dialplan (typically 'hangup').<br>
><br>
> For FreeSWITCH, the process is slightly different. Currently, rather than<br>
> create a separate socket connection for each incoming call, we're invoking<br>
> an event that informs the SafiServer that there is a new incoming call. The<br>
> event contains the contextual information including the Saflet name. For<br>
> example:<br>
><br>
> <extension name="9194"><br>
> <condition field="destination_number" expression="9194$"><br>
> <action inline="true" application="set" data="saficall=true"/><br>
> <action application="event"<br>
> data="Event-Subclass=saficall::incoming,Event-Name=CUSTOM,saflet_project=test,saflet=flow1,new_saficall=true"/><br>
><br>
> <!-- <action application="set" data="park_timeout=10"/> --><br>
> <action application="park" /><br>
> </condition><br>
> </extension><br>
><br>
> So once the event is fired, the call is parked to prevent further execution<br>
> within the dialplan. From there on, SafiServer is controlling the call via<br>
> Inbound Mod event socket.<br>
><br>
> So this works perfectly, except that if the invoked Saflet doesn't<br>
> explicitly hang-up the call it will remain parked until the caller hangs<br>
> up. My question is, is there a better way to do this? Is there some better<br>
> alternative to park in this case? Ideally I'd like to initiate a 'session'<br>
> of some kind when the SafiServer is "controlling" the call and then exit<br>
> that session as soon as the Saflet is complete, at which point the call<br>
> would continue on to the next entry in the dialplan. I understand I could<br>
> use Outbound sockets to achieve this but, as I mentioned, I'd like to avoid<br>
> the overhead of a separate socket connection for each incoming call.<br>
><br>
> I actually have a mod_saficall.c app that does basically the the same thing<br>
> as I described in the dialplan entry. Perhaps there's something more I<br>
> could do in code that would allow me to be notified when the session is<br>
> complete. Here's the relevant code I have so far:<br>
><br>
> switch_channel_t *channel = NULL;<br>
> switch_event_t *event;<br>
> const char *safiCallFlag = NULL;<br>
> channel = switch_core_session_get_channel(session);<br>
><br>
> safiCallFlag = switch_channel_get_variable(channel, "saficall");<br>
><br>
> if (!safiCallFlag)<br>
> switch_channel_set_variable(channel, "saficall", "true");<br>
><br>
><br>
> if (switch_event_create_subclass(&event, SWITCH_EVENT_CUSTOM,<br>
> "saficall::incoming") == SWITCH_STATUS_SUCCESS) {<br>
><br>
> switch_event_add_header_string(event, SWITCH_STACK_BOTTOM,<br>
> "new_saficall", safiCallFlag ? "false" : "true");<br>
><br>
> switch_channel_event_set_data(channel, event);<br>
> switch_event_fire(&event);<br>
> switch_ivr_park(session, NULL);<br>
> }<br>
><br>
> Any ideas you might have on this are welcome.<br>
><br>
> Thanks,<br>
> Zac Wolfe<br>
> Safi Systems LLC<br>
> <a href="http://www.safisystems.com" target="_blank">www.safisystems.com</a><br>
><br>
</div></div><div>> _______________________________________________<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>
><br>
<br>
<br>
<br>
</div>--<br>
Anthony Minessale II<br>
<br>
FreeSWITCH <a href="http://www.freeswitch.org/" target="_blank">http://www.freeswitch.org/</a><br>
ClueCon <a href="http://www.cluecon.com/" target="_blank">http://www.cluecon.com/</a><br>
Twitter: <a href="http://twitter.com/FreeSWITCH_wire" target="_blank">http://twitter.com/FreeSWITCH_wire</a><br>
<br>
AIM: anthm<br>
<a href="mailto:MSN%3Aanthony_minessale@hotmail.com" target="_blank">MSN:anthony_minessale@hotmail.com</a><br>
GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com" target="_blank">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> #freeswitch<br>
<br>
FreeSWITCH Developer Conference<br>
<a href="mailto:sip%3A888@conference.freeswitch.org" target="_blank">sip:888@conference.freeswitch.org</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org" target="_blank">googletalk:conf+888@conference.freeswitch.org</a><br>
pstn:+19193869900<br>
<div><div></div><div><br>
_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Zac Wolfe<br>Safi Systems LLC<br><a href="http://www.safisystems.com" target="_blank">www.safisystems.com</a><br>