Long IVR to IVR lag time

I have two IVR’s configured. The first one is the general corporate routing IVR. If users press ‘3’ then it should take them to another IVR that further breaks down where their call needs to be routed.

But we are experiencing on average an 8-10 second lag from when a user presses ‘3’ from the first IVR to when the second IVR begins playing. I’m basing this on the timer on the phone.

The first IVR has the option for callers to dial the employees extension which I’m assuming may be part of the slowdown. My timeout is set to ‘2’ and timeout retries is set to ‘0’. I’ve tried setting the timeout to 0 or even a negative number but doesn’t seem to help.

Here’s from my log file:

[2014-01-23 15:12:54] VERBOSE[18143][C-00002d58] file.c: – <SIP/510-000006c6> Playing ‘custom/greeting_mono.slin’ (language ‘en’)
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: == CDR updated on SIP/510-000006c6
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:1] Goto(“SIP/510-000006c6”, “ivr-6,s,1”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Goto (ivr-6,s,1)
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:1] Set(“SIP/510-000006c6”, “TIMEOUT_LOOPCOUNT=0”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:2] Set(“SIP/510-000006c6”, “_IVR_CONTEXT_ivr-6=ivr-5”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:3] Set(“SIP/510-000006c6”, “_IVR_CONTEXT=ivr-6”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:4] Set(“SIP/510-000006c6”, “__IVR_RETVM=”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:5] GotoIf(“SIP/510-000006c6”, “1?skip”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Goto (ivr-6,s,8)
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:8] Set(“SIP/510-000006c6”, “IVR_MSG=”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:9] Set(“SIP/510-000006c6”, “TIMEOUT(digit)=3”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] func_timeout.c: – Digit timeout set to 3.000
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:10] ExecIf(“SIP/510-000006c6”, “0?Background()”) in new stack
[2014-01-23 15:13:02] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:11] WaitExten(“SIP/510-000006c6”, “5,”) in new stack
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Timeout on SIP/510-000006c6, going to ‘t’
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:1] Set(“SIP/510-000006c6”, “TIMEOUT_LOOPCOUNT=1”) in new stack
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:2] GotoIf(“SIP/510-000006c6”, “0?final”) in new stack
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:3] Set(“SIP/510-000006c6”, “IVR_MSG=custom/ar_greeting_mono”) in new stack
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:4] Goto(“SIP/510-000006c6”, “s,start”) in new stack
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Goto (ivr-6,s,9)
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:9] Set(“SIP/510-000006c6”, “TIMEOUT(digit)=3”) in new stack
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] func_timeout.c: – Digit timeout set to 3.000
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] pbx.c: – Executing [[email protected]:10] ExecIf(“SIP/510-000006c6”, “1?Background(custom/ar_greeting_mono)”) in new stack
[2014-01-23 15:13:07] VERBOSE[18143][C-00002d58] file.c: – <SIP/510-000006c6> Playing ‘custom/ar_greeting_mono.slin’ (language ‘en’)

According to the timestamp there seems to be about 5 seconds on this particular one. Is there anyway that I can get the second IVR to play faster after the caller has entered a number?

Try disabling direct dial, it is always the case when you enable it cause * is waiting for more digits to come in. The setting is inside FreePBX’s dialplan for digit timeout, it cant (from my knowledge) be set in GUI. Default is 3 seconds i think for the next digit to timeout. So if you have IVR options with single digits, there’s no issue, cause you can ONLY enter 1 digit and the dialplan fires immediately. If you however, have Direct Dial, then those extensions (and their length) will be part of the dialplan, thus making it wait longer for more input.

We are experiencing the same problem. Each IVR takes an uncomfortable number of seconds before the announcement plays. One our end, several IVRs feed others based on time conditions. Most simply play an announcement and send to the next IVR on timeout (which is set to 0). Our settings are…

Announcement: (WAV file selected)
Direct Dial: disabled
Timeout: 0
Invalid Retries: disabled
Timeout Retries: 0
Timeout Retry Recording: none
Append Announcement on Timeout: (unchecked)
Timeout Recording: none
Timeout Destination: IVR "Menu"
Return to IVR after VM: (unchecked)
IVR Entries: (empty)

The suggestion made to Snajayws (above) did not help.

I would suggest that you need to explicitly define your timeout value. 0 probably means use the default , you can research that default value in the wiki and/or elsewhere.

Had the same thought… since 0 usually means “forever”. We’ve tried setting it to 1 and even -1. Nothing worked.

Sorry, don’t have that problem, maybe you need to file a bug report against whoever/whatever provided your current installation (you don’t say)

I figured that it had something to do with the direct dial and waiting for other digits to be input before it decides upon what to do. I was hoping that maybe there was a way to decrease the amount of time that it waits for other digits. The timeout doesn’t seem to have anything to do with that.

I guess I get the bug report as I’m the one that installed and have been configuring the system.