IVR only accepting 1 digit

All of a sudden our 3 digit extensions do not dial when direct dial is enabled. When I do a call test I see the following:

– Executing [[email protected]:14] Read("SIP/siplogic-0000002c", "IVREXT,custom/open-hours,1,0,20") in new stack

– Accepting a maximum of 1 digits.

– <SIP/siplogic-0000002c> Playing ‘custom/open-hours.slin’ (language ‘en’)

Why does it say the Maximum is 1?

What version of the IVR module:

fwconsole ma list | grep ivr

ivr | 14.0.9 | Enabled | GPLv3+

Worked fine before. Enabling Force Strict Dial Timeout seems to correct the issue for accepting the numbers to be accepted but there is an extreme long delay. Now it waits the timeout even though a match was made.

There was a change in how IVR dtmf entry works, so you need to be more careful with the ‘Force Strict Dial Timeout’ setting. The delay is configurable, if it’s too long adjust the ‘Timeout’ parameter downward.

Why do I even need it? The time out is used so a caller has time to make an entry. Now the IVR doesn’t even work unless this is enabled. Why does it have to rely on the timeout when a caller types in the extension? so IVR now requires force direct timeout?

bump. I am curious of this change. It makes no sense and now only works when the time out is met. So even if you dial extension 100 for example, you have to wait for the timeout to be met even when the digits match. This makes no sense. If you turn off Force Strict Dial timeout, it only accepts 1 digit. Why change something that worked perfect before. This new update doesn’t work correctly

No, it works fine. You’re just not understanding the difference between the two modes. Previous when you enabled “Direct Dial” on your IVR your IVR options could not be like your extensions because the IVRs have always used Background() to play the IVR message and WaitExten() to wait for the extension to be entered during the timeout.

This means that if you have extensions 100, 101, 103 and then option 1 for sales in the IVR, you would always end up sending calls to 1 for sales because WaitExten will match the 1 first. So you had to program your IVRs to not collide with dialable extensions.

Now with the “Force Strict Dial” the IVRs use the READ() function to accept digits because it will accept a variable length of digits until the timeout or # is hit. So this is why when you call a lot of places their IVR’s say “Enter X option followed by the # key” because the # terminates the entries.

Force Strict Dial is an improvement because it now allows you to have options in your IVR that can match partially like 1, 11, 111 the READ() option will let all those exist in the same IVR and route to each while non strict will always match the 1 and never let the caller get to 11 or 111.

@BlazeStudios has the complete and full correct answer to the reasoning behind this. Thank you.

1 Like

Well if I don’t have this setting on, the only thing that works is 1 digit. I need 3 digits. I guess I don’t clearly understand. The only way I can get 3 digits to work is by enabling Force Strict Dial which does not send the call if the digits are matched, it waits for the time out, then sends the call. Are you saying I need to change our recording to tell the caller to dial # after the extension has been entered?

I explained it as clearly as I could. Without “Enable Strict Dialing” set to “Yes” when FreePBX generates the dialplan for the IVR it uses the Background()/WaitExten() functions from Asterisk. WaitExten will send the digits immediately to the system. This is why it is matching against the 1 versus 100 or 111 or anything else starting with a 1.

When Strict Dialing is enabled it generates the IVR dialplan using READ() which will accept any length of digits entered and then send them when the timeout is met or # is pressed. So yes you either need to lower the timeout to something that matches or update the message to tell callers to press # so it will be accepted right away and not wait for the timeout.

any idea why this was changed? Just for the variable option? How can we get updates from sangoma on these changes before they happen.

Is the digit timeout removed in the newer version or something? Because that is what is waited on before matching a 1 versus a 103 (my Extension) on my system.

[[email protected] ~]$ sudo fwconsole ma list | grep ivr
| ivr                  | 14.0.4     | Enabled | GPLv3+     |

Version 14.0.4 has a digit timeout of 3.

If I dial into my IVR and press 1, I wait 3 seconds before it sends to option 1. Without strict turned on.

Not the WaitExten value of 10 seconds, which it would wait with Strict enabled.


With Strict enabled, it waits the 10 second value as expected.

I upgraded my IVR to edge.

Wow totally different behavior. This is a breaking change for so many people.

I have one client with an option 5 in every single IVR. Their extension range is 5100-5499. What a mess.

Why not add an option for digit timeout instead of this breaking change?

Well the only thing that I can see that is the major different is the removal of TIMEOUT(digits) which sets the timeout between DTMF input and if it’s met it will consider all entered DTMF to that point as the completed digits. Otherwise everything else is pretty much the same just done all via READ vs Background/WaitExten.

Right, but that is a major breaking change.

This is an important part of FreePBX and it should work right. IMO it’s clear what ‘right’ is, namely what everything from a $30 ATA to an analog central office line does.

There should be a long timeout, e.g. default 10 seconds and a shorter digit timeout, e.g. 3 seconds.

  1. If there is has been no input or it does not yet match anything, if the long timeout expires, the Timeout action is taken.

  2. If the input can no longer match anything, the Invalid action is taken immediately.

  3. If the input matches an option or extension number and additional input could not match anything, the selected action is taken immediately.

  4. If the input matches an option but with additional input could match an extension, if the digit timeout expires, the option action is taken.

For example: IVR has 1 for Sales, 2 for Service, 3 for Support. Extension range is 200-299.
If the customer enters 1 or 3, he is connected immediately. If 2 is entered, he gets Service after 3 seconds unless another digit is entered within that time. If e.g. 201 is entered, the extension is dialed immediately.

The only time a delay is imposed on the customer is when an option is chosen that conflicts with extension numbering. In the above example, if the extension range were 400-499, there would be no delays.

1 Like

This change makes no sense at all. Break something unannounced that worked perfect before the update. I don’t get it

1 Like

Roll back to fix.

If the customer has entered an unambiguous match, he should be connected immediately. There should be nothing to configure here. Though less important, invalid input should be immediately routed to the Invalid destination.

If the entry has not yet matched anything, the customer should be given sufficient time to make his choice. The only parameter to configure is the timeout.

The remaining case is ambiguous input. Typically, a digit was entered that is both a valid option and the first digit of an extension. Here, a delay is required to see whether more digits are coming, which should be configurable by the administrator, separate from the normal timeout. If possible, IVR options should be chosen to not conflict with extension numbering.

If a conflict is unavoidable, consider putting extension dialing in a separate IVR, e.g. “To dial an extension, press 9 followed by the extension number.”

so you are in the same boat?