[Freeswitch-users] IVR Architecture

[Anita Hall]

Hi Joao :)


On Sat, Feb 25, 2012 at 7:34 PM, João Mesquita <jmesquita at freeswitch.org>wrote:

> On Saturday, February 25, 2012 at 10:53 AM, Anita Hall wrote:
>
> 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 :(
>
> I would love to know why… How many channels are you running? Are you using
> ESL currently or mod_python? I myself use Python a lot with ESL and I've
> never hit the wall when it comes to performance despite of all the bad mojo
> Python has around it for the GIL stuff and all. And I can tell you that
> I've already done some big things.
>

Yes we are using ESL and python stackless. The python stackless interpreter
runs in a daemon mode. We run around 240 channels over E1 with FreeTDM. The
IVR is done in the same machine as FreeSWITCH. The problem that we are
facing has not to do with hitting the CPU limit. Our IVR applications make
a lot of DB and HTTP requests. Now whenever one IVR application is stuck
because of some pending DB or HTTP request, it blocks other threads as
well, since python stackless is not truly multi-threaded (Am I correct in
saying that?). Therefore, we offload the external DB and HTTP requests to
another daemon with uses RPyC library.

I do not want to run another daemon in python stackless. May be, I should
experiment some with mod_python. How many concurrent calls have you run
using python over ESL? Do you use stackless? Why or why not ? :)


>
> 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 ?
>
> If you had the need to share state between different IVRs that are being
> executed on different media servers you would know. FreeSWITCH itself is
> obviously going to need resources faster than the IVR controller, so it is
> a pretty common design to have several FS boxes with 1 IVR box controlling
> them all.
>

It is very interesting that you brought this up :) We do use a conference
server (a different machine) and use that for bridging our incoming and
outgoing calls. Conference allows us to add extra functionality which is
not possible in bridging, such as transferring the call to another agent if
the first one does not answer. (should we be using mod_fifo or
mod_callcenter for that?)

The calls are transferred from the FreeSWITCH machine to the conference
server over SIP. Is it possible to transfer the media over ESL? Do you do
bridging between different IVRs?

I like your design, but I was wondering should there be an extra IVR server
with load balancing in between?

Actually, the IVR system I am managing right now was not done by me, so I
have to do a complete makeover :) This discussion on architecture will help.

Gracias!
Anita.


>
> 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
>
>
> _________________________________________________________________________
> 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/20120226/4680552f/attachment.html