When changing Wait(1) to Wait(0) in extensions_additional.conf the file gets overwritten very quickly and all changes are lost.
Is there a way to have Wait(0) changes to announcements and IVRs in extensions_additional.conf to stay permanent other than setting immutable flag?
Thanks for your response.
No and if you set the immutable flag you might as well abandon using FreePBX at that point.
Here’s a reason Wait() should be allowed to be a configurable item. Let’s say the inbound call flow would start by playing an announcement which then proceeds to an IVR with its announcement. The current Wait(1) is a sufficient time delay which causes what is heard to the caller to not sound as if a person was speaking to them.
Since tm1000 says by setting the immutable flag on extensions_additional.conf is sufficient reason to not use FreePBX, I ask then, when does the content of extensions_additional.conf change other than using the GUI to add/remote extensions/routes/trunks etc?
Everytime you do an Apply Changes. It doesn’t matter if you didn’t edit any of the above. If you ever hit the red button then your settings are wiped out.
Here is an example of how the wait(1) is problematic.
A company can have time conditions for various times of the day. When a caller calls the company they can hear ‘good afternoon’ which should immediately be followed by the IVR announcement.
As is the case currently, the caller will hear nothing between the time condition destination announcement and the IVR announcement. Although 1 second is not a long time period, the delay breaks what the company wants the caller to hear.
There should be a way to change the value of wait() imho.
@hawkeye, your open bug on this matter is pending. The issue is not the wait statement, it is the way that FreePBX determines whether the channel is answered prior to inserting the delay.
Update IVR. the new logic is in place
After running module admin and getting updates, which included IVR update, the delay between time condition => match destination => announcement then => IVR is gone
Now when calling our DIDs it sounds excellent.