[Freeswitch-users] IVR Architecture

Mon Feb 27 02:05:53 MSK 2012

Inline, I am not a big expert so take my comments with a grain of salt.

On Sunday, February 26, 2012 at 9:30 AM, Anita Hall wrote:  
> Hi Joao :)
>  
>  
> On Sat, Feb 25, 2012 at 7:34 PM, João Mesquita <jmesquita at freeswitch.org (mailto: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.
That is far from being a large number of channels as far as ESL is concerned (and python for all I care).

> 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?).
>  
>  
>  

Yes you are correct. Python has something called GIL that prevents it from using real threads and Stackless (from what I can read on the docs) is just an implementation of green threads, just another term for "emulating threads" without really using multiple OS threads.

> 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.
I've never used mod_python, just to be clear. I asked if you were because I wouldn't be able to help if you were. I don't recommend using mod_python because the Python interpreter is something quite big to be spawned like an embedded language like that. Lua would definitely be the recommended language if you want FreeSWITCH to spawn one interpreter per channel like mod_lua would do.  
> How many concurrent calls have you run using python over ESL?
>  
>  
>  

Thousands.  
> Do you use stackless? Why or why not ? :)
No, I don't. Simply because I never had the need to. Most ppl that use Python and start reading about the GIL and the lack of native thread thing end up blaming the language for stuff they should be blaming whoever coded the application. Think for a second about what you are proposing and imagine the solution if you "had" real threads.

If you REALLY believe that you need multiple "threads", you can always use several techniques for multiprocessing. I am very fond of using ZeroMQ for FAN IN/OUT operations to several other Python processes. That way you can REALLY scale your application if you need to. If that sounds complicated (sometimes it can be overkill), look at the multiprocessing module of python. Should do the trick for "threads" that execute serial operations like I/O such as you are doing.

Careful with the snowball effect tho. If your "threads" are blocking because of I/O, maybe you need to look at the real reason for why they are blocking rather than rewriting the whole thing. Maybe RPyC is not running on async mode and therefore your task lets get stuck waiting for the lib? I cannot know until I see some code.
>   
> >  
> > > 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?)
That's a matter of taste and feature requirement. Normally I would advice you to use/improve what's already out there, ain't what open source is all about anyway?
>  
> 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?  
It is possible. With ESL you can do pretty much anything you can do on mod_lua, xml dial plan or even most C modules if you will. Of course the C module is the most flexible one, but also the most "complicated" one to get it right.  
>  
> I like your design, but I was wondering should there be an extra IVR server with load balancing in between?
Again, that depends on your requirements. The cool thing about ZeroMQ fanin/fanout thing is that you can scale horizontally if your logic is right and you don't have to keep sharing state using some type of IO bound central point such as a DB.

I can't say what you SHOULD be doing because I don't know your application and your budget or even how much you expect to grow.

>  
> 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 (mailto: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 (mailto: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 (mailto: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 (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
> > > > > >  
> > > > >  
> > > > > _________________________________________________________________________
> > > > > Professional FreeSWITCH Consulting Services:
> > > > > consulting at freeswitch.org (mailto: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 (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
> > > > >  
> > > > >  
> > > > >  
> > > >  
> > > >  
> > > >  
> > > > _________________________________________________________________________
> > > > Professional FreeSWITCH Consulting Services:
> > > > consulting at freeswitch.org (mailto: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 (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
> > > >  
> > >  
> > > _________________________________________________________________________
> > > Professional FreeSWITCH Consulting Services:
> > > consulting at freeswitch.org (mailto: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 (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
> > >  
> > >  
> > >  
> >  
> >  
> >  
> > _________________________________________________________________________
> > Professional FreeSWITCH Consulting Services:
> > consulting at freeswitch.org (mailto: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 (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
> >  
>  
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org (mailto: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 (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
>  
>  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120226/029581c6/attachment-0001.html 