What's the best language for implementing an IVR on Freeswitch
Greetings, While I've been very pleased with the stability and performance of FreeSWITCH itself, I'm having to scrap the Ruby implementation I was using to drive the call menu functionality for the IVR due to it's inability to maintain connectivity with FS via the inbound event socket. Would love some suggestions on the best approach. Lua? or some other approach? Mainly I'm looking for something that will be very stable at higher call volumes. Best regards, Terry
Depends a bit on your needs. If you can get away with the features of the ivr menu system, that will be the most performant. If not, a lot depends on what language you know best and what features you need. The language answer is usually either what you know best, or lua. Mike On Jun 6, 2013, at 10:37 AM, Terry Ray <terryjray@gmail.com> wrote:
Greetings,
While I've been very pleased with the stability and performance of FreeSWITCH itself, I'm having to scrap the Ruby implementation I was using to drive the call menu functionality for the IVR due to it's inability to maintain connectivity with FS via the inbound event socket.
Would love some suggestions on the best approach. Lua? or some other approach?
Mainly I'm looking for something that will be very stable at higher call volumes.
Best regards,
Terry
Terry, You place blame on the client implementation, but I've already expressed to you that my feeling is that this is a FS bug. Do you have a reference to your FS JIRA that I may look at to ascertain what the FS team think? https://github.com/adhearsion/adhearsion/issues/311 Regards, Ben Langfeld On 6 June 2013 11:37, Terry Ray <terryjray@gmail.com> wrote:
Greetings,
While I've been very pleased with the stability and performance of FreeSWITCH itself, I'm having to scrap the Ruby implementation I was using to drive the call menu functionality for the IVR due to it's inability to maintain connectivity with FS via the inbound event socket.
Would love some suggestions on the best approach. Lua? or some other approach?
Mainly I'm looking for something that will be very stable at higher call volumes.
Best regards,
Terry
_________________________________________________________________________ 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
Guys, Cross posted to your github Its unlikely that the ESL server would stop sending events that have already been subscribed unless maybe a filter was placed on it or the events were unsubscribed. This is not very difficult to test.
From another shell, use fs_cli to get into the cli, then issue a similar events command from there e.g. /events channel_originate channel_hangup heartbeat Just use whatever events....
Many implementations of client side ESL experience issues where they do not properly cache any events read between the sending of an event and getting the reply, those need to be saved and parsed afterwards. You can easily monitor the traffic on the wire with ngrep ngrep -d any -W byline tcp and port 8021 change any to lo or eth0 etc if desired and adjust the port as needed. On Thu, Jun 6, 2013 at 10:13 AM, Ben Langfeld <ben@langfeld.co.uk> wrote:
Terry,
You place blame on the client implementation, but I've already expressed to you that my feeling is that this is a FS bug. Do you have a reference to your FS JIRA that I may look at to ascertain what the FS team think?
https://github.com/adhearsion/adhearsion/issues/311
Regards, Ben Langfeld
On 6 June 2013 11:37, Terry Ray <terryjray@gmail.com> wrote:
Greetings,
While I've been very pleased with the stability and performance of FreeSWITCH itself, I'm having to scrap the Ruby implementation I was using to drive the call menu functionality for the IVR due to it's inability to maintain connectivity with FS via the inbound event socket.
Would love some suggestions on the best approach. Lua? or some other approach?
Mainly I'm looking for something that will be very stable at higher call volumes.
Best regards,
Terry
_________________________________________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
@Mike, thanks for the suggestions. I've got to dig a little deeper on the options but Lua seems to be a decent choice. @Ben, my apologies. I certainly am willing to say the fault lies with my inability to get the solution working and getting the level of debugging necessary to place 'blame.' It's not my intention to find fault with either of two (IMO) really cool open source efforts. But at this point, employing tcpdump and other diagnostic tools to dig in enough to discover irrefutable evidence is more time consuming than simply doing a quick re-write, especially since I'm working on someone else's nickel ;) Hopefully, I'll have time to revisit and contribute Kind regards, Terry
participants (4)
-
Anthony Minessale
-
Ben Langfeld
-
Michael Jerris
-
Terry Ray