Hello, There appears to be a delay of 1 second between menu events within an IVR (i.e. play long, invalid option, play short). We have the following IVR menu; <menu name="ivr.2" greet-long="phrase:demo_ivr_main_menu" greet-short="phrase:demo_ivr_main_menu" exit-sound="phrase:demo_ivr_main_menu" confirm-macro="" confirm-key="" confirm-attempts="3" timeout="10000" inter-digit-timeout="10" max-failures="3" max-timeouts="3" digit-len="1"> In the above example, any option will result in an invalid selection being met. However, FS seems to take its sweet time getting from the point of a user pushing a button, to actually playing the next audio. freeswitch@vded213> 2012-12-07 16:17:21.752141 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 2:2240 2012-12-07 16:17:21.752141 [DEBUG] switch_ivr_play_say.c:1682 done playing file /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:395 digits '2' 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:579 IVR menu 'ivr.2' caught invalid input '2' 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:67 No language specified - Using [en] 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:244 Handle play-file:[ivr/ivr-welcome_to_freeswitch.wav] (en:en) 2012-12-07 16:17:22.872155 [DEBUG] switch_core_file.c:180 File /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav sample rate 48000 doesn't match requested rate 8000 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:1309 Codec Activated L16@8000hz 1 channels 20ms In the above, you can see the IVR knew the menu was invalid at "16:17:21.872105", but didn't start playing the next audio until "16:17:22.872155". The difference between the two is almost exactly 1 second, which makes me think maybe there's a config option somewhere that isn't documented/obvious, or a hard coded delay. Any advice on this would be much appreciated, slow/laggy menus are a pet hate of mine :/ Thanks Cal
Are you sure it's not timing out? Change the timeout="10000" to timeout="30000" and see if your lag is now 3 seconds. On Fri, Dec 7, 2012 at 1:23 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello,
There appears to be a delay of 1 second between menu events within an IVR (i.e. play long, invalid option, play short).
We have the following IVR menu;
<menu name="ivr.2" greet-long="phrase:demo_ivr_main_menu" greet-short="phrase:demo_ivr_main_menu"
exit-sound="phrase:demo_ivr_main_menu" confirm-macro="" confirm-key="" confirm-attempts="3" timeout="10000" inter-digit-timeout="10" max-failures="3" max-timeouts="3" digit-len="1">
In the above example, any option will result in an invalid selection being met.
However, FS seems to take its sweet time getting from the point of a user pushing a button, to actually playing the next audio.
freeswitch@vded213> 2012-12-07 16:17:21.752141 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 2:2240 2012-12-07 16:17:21.752141 [DEBUG] switch_ivr_play_say.c:1682 done playing file /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:395 digits '2' 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:579 IVR menu 'ivr.2' caught invalid input '2' 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:67 No language specified - Using [en] 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:244 Handle play-file:[ivr/ivr-welcome_to_freeswitch.wav] (en:en) 2012-12-07 16:17:22.872155 [DEBUG] switch_core_file.c:180 File /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav sample rate 48000 doesn't match requested rate 8000 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:1309 Codec Activated L16@8000hz 1 channels 20ms
In the above, you can see the IVR knew the menu was invalid at "16:17:21.872105", but didn't start playing the next audio until "16:17:22.872155".
The difference between the two is almost exactly 1 second, which makes me think maybe there's a config option somewhere that isn't documented/obvious, or a hard coded delay.
Any advice on this would be much appreciated, slow/laggy menus are a pet hate of mine :/
Thanks
Cal
_________________________________________________________________________ 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
-- Guillermo Ruiz Camauer
Thanks for the response, although this sadly isn't the cause. timeout uses milliseconds, of which 10000 which would equate to 10 seconds. Plus, digit-len is set to 1, so it should automatically search for an entry after the first button push. Cal On Fri, Dec 7, 2012 at 4:29 PM, Guillermo Ruiz Camauer <grcamauer@gmail.com>wrote:
Are you sure it's not timing out? Change the timeout="10000" to timeout="30000" and see if your lag is now 3 seconds.
On Fri, Dec 7, 2012 at 1:23 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello,
There appears to be a delay of 1 second between menu events within an IVR (i.e. play long, invalid option, play short).
We have the following IVR menu;
<menu name="ivr.2" greet-long="phrase:demo_ivr_main_menu" greet-short="phrase:demo_ivr_main_menu"
exit-sound="phrase:demo_ivr_main_menu" confirm-macro="" confirm-key="" confirm-attempts="3" timeout="10000" inter-digit-timeout="10" max-failures="3" max-timeouts="3" digit-len="1">
In the above example, any option will result in an invalid selection being met.
However, FS seems to take its sweet time getting from the point of a user pushing a button, to actually playing the next audio.
freeswitch@vded213> 2012-12-07 16:17:21.752141 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 2:2240 2012-12-07 16:17:21.752141 [DEBUG] switch_ivr_play_say.c:1682 done playing file /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:395 digits '2' 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:579 IVR menu 'ivr.2' caught invalid input '2' 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:67 No language specified - Using [en] 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:244 Handle play-file:[ivr/ivr-welcome_to_freeswitch.wav] (en:en) 2012-12-07 16:17:22.872155 [DEBUG] switch_core_file.c:180 File /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav sample rate 48000 doesn't match requested rate 8000 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:1309 Codec Activated L16@8000hz 1 channels 20ms
In the above, you can see the IVR knew the menu was invalid at "16:17:21.872105", but didn't start playing the next audio until "16:17:22.872155".
The difference between the two is almost exactly 1 second, which makes me think maybe there's a config option somewhere that isn't documented/obvious, or a hard coded delay.
Any advice on this would be much appreciated, slow/laggy menus are a pet hate of mine :/
Thanks
Cal
_________________________________________________________________________ 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
-- Guillermo Ruiz Camauer
_________________________________________________________________________ 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
Just trawled through the source and found this; src/switch_ivr_menu.c: if (status == SWITCH_STATUS_SUCCESS) { status = switch_ivr_sleep(session, 1000, SWITCH_FALSE, NULL); } So, I changed 1000 to 10, the delay has now disappeared and it seems to work perfectly. Could a core dev please explain why this sleep call is needed, and would there be any unforeseen side effects by reducing it? If there are no side effects, I'd like to make a suggestion to have this reduced, or at least make it adjustable via config. Use case for reducing? Slow menus are really, really annoying. Thanks Cal On Fri, Dec 7, 2012 at 7:32 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Thanks for the response, although this sadly isn't the cause.
timeout uses milliseconds, of which 10000 which would equate to 10 seconds.
Plus, digit-len is set to 1, so it should automatically search for an entry after the first button push.
Cal
On Fri, Dec 7, 2012 at 4:29 PM, Guillermo Ruiz Camauer < grcamauer@gmail.com> wrote:
Are you sure it's not timing out? Change the timeout="10000" to timeout="30000" and see if your lag is now 3 seconds.
On Fri, Dec 7, 2012 at 1:23 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Hello,
There appears to be a delay of 1 second between menu events within an IVR (i.e. play long, invalid option, play short).
We have the following IVR menu;
<menu name="ivr.2" greet-long="phrase:demo_ivr_main_menu" greet-short="phrase:demo_ivr_main_menu"
exit-sound="phrase:demo_ivr_main_menu" confirm-macro="" confirm-key="" confirm-attempts="3" timeout="10000" inter-digit-timeout="10" max-failures="3" max-timeouts="3" digit-len="1">
In the above example, any option will result in an invalid selection being met.
However, FS seems to take its sweet time getting from the point of a user pushing a button, to actually playing the next audio.
freeswitch@vded213> 2012-12-07 16:17:21.752141 [DEBUG] switch_rtp.c:3797 RTP RECV DTMF 2:2240 2012-12-07 16:17:21.752141 [DEBUG] switch_ivr_play_say.c:1682 done playing file /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:395 digits '2' 2012-12-07 16:17:21.872105 [DEBUG] switch_ivr_menu.c:579 IVR menu 'ivr.2' caught invalid input '2' 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:67 No language specified - Using [en] 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:244 Handle play-file:[ivr/ivr-welcome_to_freeswitch.wav] (en:en) 2012-12-07 16:17:22.872155 [DEBUG] switch_core_file.c:180 File /usr/local/freeswitch/sounds/en/us/callie/ivr/ivr-welcome_to_freeswitch.wav sample rate 48000 doesn't match requested rate 8000 2012-12-07 16:17:22.872155 [DEBUG] switch_ivr_play_say.c:1309 Codec Activated L16@8000hz 1 channels 20ms
In the above, you can see the IVR knew the menu was invalid at "16:17:21.872105", but didn't start playing the next audio until "16:17:22.872155".
The difference between the two is almost exactly 1 second, which makes me think maybe there's a config option somewhere that isn't documented/obvious, or a hard coded delay.
Any advice on this would be much appreciated, slow/laggy menus are a pet hate of mine :/
Thanks
Cal
_________________________________________________________________________ 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
-- Guillermo Ruiz Camauer
_________________________________________________________________________ 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
I've raised a JIRA ticket for this; http://jira.freeswitch.org/browse/FS-4924 Cal On Fri, Dec 7, 2012 at 8:08 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Just trawled through the source and found this;
src/switch_ivr_menu.c: if (status == SWITCH_STATUS_SUCCESS) { status = switch_ivr_sleep(session, 1000, SWITCH_FALSE, NULL); }
So, I changed 1000 to 10, the delay has now disappeared and it seems to work perfectly.
This has now been patched in the core (sleep has been completely removed), see JIRA ticket for details. Thanks Ant! Cal On Sat, Dec 8, 2012 at 9:09 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
I've raised a JIRA ticket for this; http://jira.freeswitch.org/browse/FS-4924
Cal
On Fri, Dec 7, 2012 at 8:08 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Just trawled through the source and found this;
src/switch_ivr_menu.c: if (status == SWITCH_STATUS_SUCCESS) { status = switch_ivr_sleep(session, 1000, SWITCH_FALSE, NULL); }
So, I changed 1000 to 10, the delay has now disappeared and it seems to work perfectly.
Another satisfied customer... and proof that opening a Jira not only makes Tony's life easier, it actually WORKS! Thanks for opening the Jira and thanks for reporting that your issue has been resolved. -MC On Sun, Dec 9, 2012 at 2:57 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
This has now been patched in the core (sleep has been completely removed), see JIRA ticket for details.
Thanks Ant!
Cal
On Sat, Dec 8, 2012 at 9:09 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
I've raised a JIRA ticket for this; http://jira.freeswitch.org/browse/FS-4924
Cal
On Fri, Dec 7, 2012 at 8:08 PM, Cal Leeming [Simplicity Media Ltd] < cal.leeming@simplicitymedialtd.co.uk> wrote:
Just trawled through the source and found this;
src/switch_ivr_menu.c: if (status == SWITCH_STATUS_SUCCESS) { status = switch_ivr_sleep(session, 1000, SWITCH_FALSE, NULL); }
So, I changed 1000 to 10, the delay has now disappeared and it seems to work perfectly.
_________________________________________________________________________ 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
-- Michael S Collins Twitter: @mercutioviz http://www.FreeSWITCH.org http://www.ClueCon.com http://www.OSTAG.org
participants (3)
-
Cal Leeming [Simplicity Media Ltd]
-
Guillermo Ruiz Camauer
-
Michael Collins