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.
[jbusch@pbx ~]$ 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.
-
If there is has been no input or it does not yet match anything, if the long timeout expires, the Timeout action is taken.
-
If the input can no longer match anything, the Invalid action is taken immediately.
-
If the input matches an option or extension number and additional input could not match anything, the selected action is taken immediately.
-
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?
There are many changes to freepbx made weekly. We do not announce all of them. There would be so much noise you’d probably end up ignoring it. This change is in the change log. That has always existed. You can follow the change log and see the ticket releated to it. You can also see the QA it went through as well.
Do you really want announcements for every change. You might want to reply with “only with breaking changes”. Please note that something that is breaking for you is not breaking for someone else.
The result of this is because someone else said ivr was totally useless and gave a bunch of reasons why. So we implemented this change for them. Now you want to revert what works for them for you. So revert the breaking change for you that would be a breaking change for them. This is what makes running this project so hard. It can make no sense to you all day long but it can make complete sense to someone in an entirely different boat. There are millions of systems.
That said we will look into a solution on this for everyone. All you have to do is ask. It’s in EDGE right now for a reason. Why are you running edge on production systems?
1 Like
Only because I manually upgraded the edge to test this
We had to run edge to fix the Alert info issues where the ring tone wouldn’t change. How do I revert the IVR and to which version. Yes this makes sense 
Go to module admin, click check online, expand IVR and click on previous, rollback to the latest previous version and test…
https://issues.freepbx.org/browse/FREEPBX-19475
Added new setting of ‘No - Legacy’ to strict dial timeout. This is the default moving forward and upgrades should move into this mode automatically. As for previous upgrades you’ll have to go into your IVRs and set this to ‘No - Legacy’ and it should work as intended.
5 Likes
This wasn’t a previous upgrade, so I am confused on this.
I just upgraded a system to IVR 14.0.9.1 from 14.0.4 and none of the existing IVR were changed to No-Legacy. They stayed on No.
Yes. It was. Anything higher than 14.0.3 is a “previous” upgrade
Because 14.0.4 already had “Force Strict Dial Timeout”. This is working as intended. You’d have to be earlier than 14.0.3
Ok, the report was originally on 14.0.8 (edge), so now we know.
The best upgrade then would be to downgrade to 14.0.3 first and then upgrade to 14.0.9.1 in order to force things to work properly (read: as they always have).
For anyone that does not want to downgrade and then upgrade, but also does not want to change many IVR (my test system had 35), you can use this SQL from a root command prompt. It will change all IVR that are No to No-Legacy
mysql -e "UPDATE asterisk.ivr_details SET strict_dial_timeout = 2 WHERE strict_dial_timeout = 0;"
fwconsole reload
This topic was automatically closed after 13 days. New replies are no longer allowed.