* Calculate timeout for Follow-me
Need to calculate the timeout for Enterprise RG members that have extensions with follow-me.
The RG timeout should always take precedence over a follow-me timeout value. What we do is take the delay of the follow-me destination and subtract that from the ring group timeout to give us the total timeout of the destination.
Example:
RG 1: x1000 (Delay=0, Timeout=10)
RG 2: x2000 (Delay=10, Timeout=10)
x2000 has follow-me enabled
FM 1: x2000 (Delay=0, Timeout=15)
FM 2: x3000 (Delay=5, Timeout=20)
In this example we would want x2000 ring for 10 seconds and x3000 to ring for 5 seconds.
What if we changed this... FM 2: x3000 (Delay 15, Timeout=20)
In this example we wouldn't want x3000 to ring at all because it would start to ring after the RG timeout has expired. Our calculated value would be a negative value, -5. These negative values don't work as leg_timeouts in the dialstring, so we need to test for them.
* Update index.lua
* Update index.lua
This is related to 9dcaddd814 (diff-b1f5588538149bd825603176ff81d714).
For internal calls the delay needs to be "Delay In Seconds * 500".
For external calls the delay needs to be "Delay In Seconds * 10000".
For external calls I'm am just doubling the value set prior in the script.
We need to make sure that the delay for the leg takes into account the delay from the RG and from Follow-me.
Also, let's use the timeout from the RG instead of the follow-me member
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.
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?
This scenario was broken:
A ring group member forwards their phone to a destination. The destination is an external number and the outbound route had a toll_allow condition.
This error would be generated: [ERR] switch_cpp.cpp:1376 [route_to_bridge] Unsupportded condition: ${toll_allow}
This PR will get the toll_allow values from the RG member that is forwarding their phone. Then it will pass it to 'route_to_bridge.lua'.
* Add. Use `route_to_bridge` module to build routes fro ring groups.
This commit has several improvements
1. Select only needed fields. (do not select quite big XML text strings)
2. Filter routes also by context name
3. Filter dialplans also by hostname
4. Handle conditions based not only `destination_number`
5. Handle `break` and `continue` attributes for extensions
6. Escape vars inside dial-string
7. Add log messages similar as FS dialplan do
* Add. `route_to_bridge` set inline vars so it possible use then in next conditions.
Add. `route_to_bridge` can execute basic api commands from allowed lists.
`route_to_bridge` expand all known vars. If var is unknown then it pass as is.
Fix. `export nolocal:` action.
* Fix. Short variable names
* Add. some comments
* Fix. Do not try execute empty string
This produce error messages `[ERR] switch_cpp.cpp:759 No application specified`
* Fix. Export nolocal values.
FusionPBX
agree
konradSC
emaktech
borisk1976
Alexey Melnichuk