This is going to sound really stupid but I have tested this extensively, submitted a Jira on it months ago (was told FS 1.6.20 was no longer supported) and it's still an issue. Please do not take my word for this and create a ring group to test the delay settings with a stopwatch and you should see the real vs set delay discrepancy.
In FreeSWITCH (both on 1.6.20 and 1.8.5) when sending leg_delay_start values, for whatever reason the actual time is double the value sent. The result of this is that if you send 1000ms as leg_delay_start the actual time the call will be delayed is 2000ms.
Because of this bad behavior, ring group delay settings end up being exactly double what is set. e.g. if you set 10s, you will have to wait 20s for the call to be initiated on leg b.
The easiest way to fix this behavior is to simply multiply leg_delay_start by half as much to get the right "real" delay time. Ugly, I know... I'm not sure if leg_delay_start value is passed elsewhere, I'm thinking this behavior may also be present in find me/follow me. If this gets accepted I will look for other locations where this behavior occurs and submit separate PRs if I find any other instances of this.
When setting call_block_matching, the setting was not being evaluated as true because it was looking for 'call block' group when the actual name is 'call_block'.
Adding the underscore fixes this small syntax issue and the setting works correctly.
This patch adds BING (legacy) some extra fault tolerance support. For those who still use Bing, Bing sometimes fails
It adds another way, which I think it is easier and faster (Azure). Among the outstanding things it has; just configure the zone, and use Memcache to store the access token as per Azure documentation, it saves a query (faster). It also returns the most likely right transcription (digging in the JSON)
Two things:
1. Follow-me should only kick in when using "Enterprise". As it was written, follow-me was looked at for every strategy.
2. Follow-me destinations were writing to 'destinations[x]'. They should write to 'destinations[key]' so they rewrite the current destination that is being analyzed.
When bridge application ends with "originate_disposition: ALLOTTED_TIMEOUT" for example, the "missed call" feature doesn't work for ring group because of hangup hook isn't called. Should we just avoid using this channel variable or add additional processing at the end? Like for timeout action? I choose to call "missed" at the end of script. But may be we should add it to other places too?
* Make storage_path work
if storage_path was set, the script would fail. I have fixed it by removing the references to unset variables. I also made the recordings use the path.
* Update ivr.conf.lua
Add storage_path definition so storage_type of http_cache works correctly
* Added a simple selfhosted voicemail transcription API client
* Minor logging cleanup
* Add some string escaping to handle transcription providers
* Add JSON handling (optional) to selfhosted API
