Voicemail Transcription with Azure

[jwrite]

I seem to be having an problem getting transcription to work with Azure in the long term.

I followed the instructions for setting up the voicemail transcription to work and everything seems to be fine for the first transcription, but on subsequent transcriptions (an hour or so later) it would fail.

That got me looking into the code and it seems that the script saves the azure access token to cache and doesn't let it go, and since the access token is only valid for 10 minutes or so, any messages sent after the 10 minute period would be expected to fail, and that's exactly what they do...

To confirm this is the problem I cleared the cache using the button from the web interface under sip status and... voicemail transcription works again for the next 10 minutes.

While I'm doing this I'm keeping an eye on the logs and I will keep getting the following message until I click Flush Cache:

[NOTICE] switch_cpp.cpp:1465 [voicemail] Azure access_token recovered from memcached

After I click Flush Cache it will actually go fetch the new token and everything will work for the next 10 minutes.


So a little more reading and I found out that the token caching was intended to work with memcache, and since this is a newer installation it defaults with a file based caching. So I try to change the cache method to memcache and even change the location to /tmp in default settings, reload, and restart the server but I keep finding cache in the /var/cache/fusionpbx folder.. specifically, app.voicemail.azure.access_token after I run the voicemail transcription

To further that, when I click flush cache from the web interface it no longer clears the files in /var/cache/fusionpbx... even when I had the location still pointing to that directory.

So my question is this.. Am I doing something wrong with converting the system caching to memcached? Or is the voicemail transcription with azure a known issue? If so, is there a fix for this anywhere? Aside from commenting out the line for getting the cache record?

Thank you!
John

 

[bbardon]

Had the same problem. From reading various threads here, I found that replacing the latest /usr/share/freeswitch/scripts/app/voicemail/resources/functions/record_message.lua with an older version got things working. I am using a version from Jan 15th 2021 and transcription is working. You have to save the working file outside the fusion directory, so when you update, you can copy it in again.

 

[Konrad M WebArray]

@jwrite I literally just answered a similar but older question here:

Re: Speech to text api seems not responding (Voicemail Transcription with Azure on FusionPBX/FreeSwitch) - Microsoft Q&A

This is a proposed answer to a question that was originally posted by ClearConverse over here: https://social.msdn.microsoft.com/Forums/en-US/b06ad362-4eb7-44ee-8b84-4ce4b8b3fd20/speech-to-text-api-seems-not-responding The original question relates…

docs.microsoft.com

@bbardon You can use the current version just comment out the line in record_message.lua that either saves the cache or reads the cache for the file. Also if you update to /var/www/fusion....................../record_message.lua then your settings should persist after update settings in the web interface. In terms of global updates, you're correct, keep a backup or comment out the lines. Hopefully by the next release this would be addressed.

Aside from commenting out the caching function you can also set a 5 minute expiry and save it to the cache as well but since Azure varies the token expiry time it would be better to read the token to find the expiry, compare it to a current UTC timestamp and use the difference as your expiry limit.

Good luck!

 

[bbardon]

Good to know, thanks!

 

[Jonathan Black]

An alternative solution, suggested to me by someone official, was to set this line in your crontab (crontab -e)
*/15 * * * * rm /var/cache/fusionpbx/app.voicemail.azure.access_token

It just deletes the token from cache every 15 minutes. As Konrad suggested, it would be better to create an accurate expiry, but this solution has the advantage of reusing the token for at least a while, instead of never saving/reading it. It has worked for us for most of a year, through a couple of upgrades, with no coding changes.

Note that I did look into this issue a year or two ago and found that memcached supports an expiry time. The file-based cache currently in use in FusionPBX does not. I had cobbled together a solution using a second cached item as the expiry, but then when the author created the separate email queue process, it broke. For what we need, the above solution seems to work as well.