[Freeswitch-users] New FreeSWITCH IVR coming, but need HELP!

[Yitzchok]

Do you mean that you want that when the IVR is done without a hangup command
it should continue down the xml file?


Yitzchok


On Mon, Jan 10, 2011 at 5: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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20110111/63a72062/attachment.html