* Fix table name, variables and syntax Follow me Lua
Correct the wrong table name on line 123. Correct the param on line 126 and correct the syntax on line 347.
* Update index.lua
Missing AND in where clause.
* Change order of preference Caller ID
Changed order of preference for Caller ID. If user exists should take preference over Follow Me override select caller ID.
This is my preference and my opinion only. May not be the desired effect of others. Perhaps a select option to choose a preference like the following options: Set caller ID override all, Local user else Caller ID
* 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
The following PR is for voicemail transcription using IBM Watson.
https://cloud.ibm.com/catalog/services/speech-to-text
The following values need to be configured in Default Settings:
Category: Voicemail
Subcategory: watson_key
type: text
Value: [Your Watson api key ]
Category: Voicemail
Subcategory: json_enabled
type: boolean
Value: true
Category: Voicemail
Subcategory: transcibe_language
type: text
Value: en-US
Category: Voicemail
Subcategory: transcribe_provider
type: text
Value: watson
Category: Voicemail
Subcategory: watson_url
type: text
Value: https://stream.watsonplatform.net/speech-to-text/api/v1/recognize?model=en-US_NarrowbandModel
Category: Voicemail
Subcategory: transcribe_enabled
type: boolean
Value: true
Reload Default Settings. I Flushed Cache and Reloaded XML just for good measure.
Also make sure transcription is set to TRUE in your voicemail box.
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.
With the current implementation, Phrases cannot be used in IVRs as streamfile.lua prevents keypresses from being passed back to the IVR. This fix makes a small change to the way phrases are stored and allows streamfile to be run without blocking IVR keypresses.
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.
Added and optional parameter, argv[2], to take a domain_uuid. This is to fix an issue where if two contact records exist with the same phone number, but in different domains, the CID lookup would always pick the same contact record irrespective of which domain the inbound number belonged to.
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.
FusionPBX
Stephen Forster
agree
Luis Daniel Lucio Quiroz
konradSC
emaktech
blackwolfresearch
jpattWPC
Bryan Redeagle
Adrian Fretwell
ednt