[Freeswitch-users] IVR Architecture

[Anita Hall]

Thanks Joao

Yes, language selection depends on what we want to do. Currently, we are
using python stackless for running multi-threaded IVR in FreeSWITCH but we
are not happy :(

Similarly, I am note sure about multi-threading in Lua.

Multi-threading in C is stable. I am also wondering if the built-in XML
engine runs on the same FreeSWITCH thread as the incoming call ?

Why have you found a need to run the IVR on a different box than the
FreeSWITCH server? We currently run the IVR on the Media server itself
(which is FreeSWITCH). We are taking incoming / outgoing calls over PRI/E1.
Even when we change to SIP calls, the media server itself can run both FS
and the IVR. What could be an advantage in doing it on separate machines ?

Thanks.

regards,
Anita



On Fri, Feb 24, 2012 at 11:58 AM, João Mesquita <jmesquita at freeswitch.org>wrote:

> In my opinion, the language you are using pretty much depends on the
> project requirements. C will always be faster then anything else if
> implemented correctly. Also, there is advantages of using native APIs (no
> matter with ESL or as a module).
>
> Nonetheless, the implementation is more complex, requires more knowledge
> and at last and most important, TIME. Do you have the time and resources to
> do it in C and will it be justified based on the project budget you have?
>
> Other then that, I would use ESL because you get the benefit of having
> your application running on another box and even have it control several
> boxes at once which is a common requirement for large IVRs.
>
> I hope it helps.
>
> Regards,
>
> --
> João Mesquita
> Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
>
> On Friday, February 24, 2012 at 4:29 AM, Vitalie Colosov wrote:
>
> Why not to use powerful and fast lua scripts with DB access - example for
> DB select:
> ------------------------
> subscriber = "1000";
> my_field = '';
> local dbh = assert(freeswitch.Dbh("db","fs_user","fs_password"));
> dbh:query("select my_field1 from my_table1 where subscriber =
> '"..subscriber.."'",
> function(row)
> my_field = row.my_field1;
> end);
> dbh:release();
> --do whatever you need here!!
> ------------------------
>
> obviously you need to configure ODBC for access, but this is described:
> http://wiki.freeswitch.org/wiki/Using_ODBC_in_the_core#CentOS_5.2
>
>
> 2012/2/23 Anita Hall <anita.hall at simmortel.com>
>
> Hi
>
> We are considering writing our own module for processing IVR in C. We are
> considering using mod_event_socket and then modify it to consume and
> produce the events internally instead of passing them to the socket. Is
> this a good idea?
>
> I know FreeSWITCH already has a mod_dialplan_xml which can use mod_curl to
> communicate to the outside world for I/O and DB access. But ...
>
> 1) Does XML have all the power flexibility that will be needed for
> powerful IVR applications?
>
> 2) Does mod_dialplan_xml use a separate thread for each IVR execution ?
> What will be the overhead of interpreting the XML ?
>
> 3) Any more ideas ?
>
> Thanks :)
>
> regards,
> Anita
>
>
> _________________________________________________________________________
> 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
>
>
> _________________________________________________________________________
> 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
>
>
>
> _________________________________________________________________________
> 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/20120225/cdb78cf7/attachment.html