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.

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 ?
What does it matter what thread it runs in? 

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.
 
Thanks.

regards,
Anita



On Fri, Feb 24, 2012 at 11:58 AM, João Mesquita <jmesquita@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

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:


2012/2/23 Anita Hall <anita.hall@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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:

FreeSWITCH-powered IP PBX: The CudaTel Communication Server

Official FreeSWITCH Sites

FreeSWITCH-users mailing list


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@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@freeswitch.org
http://www.freeswitchsolutions.com

FreeSWITCH-powered IP PBX: The CudaTel Communication Server
http://www.cudatel.com

Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org