[Freeswitch-users] Complex IVRs using data from MySQL

[Telecube - John]

Hi guys,

Thanks for the info, I'm still trying to find the best solution for me. 
It's looking like handling it all in a lua script might be the way to go.

However I would welcome expert opinions on the following concept.

The call routes into the IVR and the following entry captures a 4 digit 
keypress and sends the data to the lua script:

<entry action="menu-exec-app" digits="/^(\d{4})$/" param="transfer $1 
LUA ivr-get-data.lua"/>

And either:

The script does the db lookup and retrieves the destination number from 
the database and sends the call back into the default context:

table.insert(ACTIONS, {"transfer", "0398776544 XML default"})

The destination number is matched and routed out as normal.

or

The script retrieves further detail from the database and sends the call 
back into the ivr_next_level context and we do the dance again:

table.insert(ACTIONS, {"transfer", "101323556 XML ivr_next_level"})


In terms of speed and system resources is this an efficient way to 
handle a variable keypress IVR with possible multiple levels?

- John


On 19/05/13 4:10 AM, Dave R. Kompel wrote:
> Just from my experence, it's a lot easier to write the whole logic, 
> for a complex IVR in something (lua, perl, python, C#, F#) or anything 
> else that FS supports, rather then trying to cram it in to the simple 
> IVR application. Remember you can do foreign DB access or talk to 
> anything else (web service, raw http service, etc...) from any of the 
> languages directly.
> I do almost all external interaction with C# modules, runnig inside of 
> FS. Makes life real easy :)
> --Dave
>
>     ------------------------------------------------------------------------
>     *From:* Brian Foster [mailto:bdfoster at davri.com]
>     *To:* FreeSWITCH Users Help
>     [mailto:freeswitch-users at lists.freeswitch.org]
>     *Sent:* Sat, 18 May 2013 09:49:59 -0700
>     *Subject:* Re: [Freeswitch-users] Complex IVRs using data from MySQL
>
>     Whether or not you hand it back to mod_ivr or not, to set a
>     channel variable in Lua:
>
>     session:setVariable("varname", "varvalue");
>
>     This has the same effect as using the set application in the dialplan:
>
>     <action application="set" data="varname=varvalue"/>
>
>     You can read the variable in Lua like this:
>
>     varname = session:getVariable("varname");
>
>     -BDF
>
>     On May 18, 2013 12:35 PM, "Telecube - John" <john at telecube.com.au
>     <mailto:john at telecube.com.au>> wrote:
>
>         Ok, if someone could point me in the right direction I would
>         be very
>         grateful.
>
>         I need to integrate database lookups into multi level IVRs to
>         gather
>         call routing info.
>
>         The lookups are for variable multi digit keypress data as well as
>         multiple sets of routing information.
>
>         So far I can see my options are xml_curl or hand the call off
>         to a lua
>         script to handle the processing.
>
>         I can catch the multi digit keypresses with regex and give
>         that detail
>         to a lua script, no problem.
>
>         I'm hoping to be able to use the mod_ivr process as much as
>         possible but
>         I'm struggling to see how I can get data back into the call
>         flow after
>         dishing the duty off to lua.
>
>         Can anyone point me down the right path please?
>
>         Should I be happy to pass it off to lua and finish the lookups and
>         routing in there?
>
>         Should I try to keep as much as possible in the core ivr?
>
>         Thanks..
>
>         - John
>
>         _________________________________________________________________________
>         Professional FreeSWITCH Consulting Services:
>         consulting at freeswitch.org <mailto:consulting at freeswitch.org>
>         http://www.freeswitchsolutions.com
>         <http://www.freeswitchsolutions.com/>
>
>         
>          </>
>
>         Official FreeSWITCH Sites
>         http://www.freeswitch.org <http://www.freeswitch.org/>
>         http://wiki.freeswitch.org <http://wiki.freeswitch.org/>
>         http://www.cluecon.com <http://www.cluecon.com/>
>
>         FreeSWITCH-users mailing list
>         FreeSWITCH-users at lists.freeswitch.org
>         <mailto: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 <http://www.freeswitch.org/>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.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/20130519/56afba54/attachment-0001.html