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