GavinJ

The RPS flag all works perfectly for us too, it's just the filling of the "static" parameter. Without the "static" parameter, the provisioning URL isn't visible in the GUI of the Yealink handsets. Not sure if this might have been an intentional change on Yealink's behalf with newer firmware. Essentially what it looks like from what I can see is that if you don't have the "static" keyword, then the phone will request a provision from the URL once and then drop the url config. Which is where we run into trouble if we make a button layout change and then trigger a provision remotely the handset no longer has the provisioning settings. It was all working really well for us, it changed around about the version where it was discovered that Vodia needed to parse the Yealink config first. it was at that same time that we pushed out handset upgrades too, so I never took notice if they keyword had changed in the template or not.

In the yealink_common provisioning template there is the following block: {if rps == "1"} # We still need to set the provisioning server auto_provision.server.url = {get http_scheme}{get http_host}/yealink-{mac}.cfg {elif https != "true" && model != "t38g" && provision_https == "true"} static.trusted_certificates.url = http://{get host}:{http-port}/yealink_cert.pem auto_provision.server.url = https://{get host}:{https-port}/yealink-{mac}.cfg {fi} We are seeing our new customers handsets that we setup with the Yealink RPS service not have the auto_provision url set, and therefor requests for the handsets to resync are failing because they don't have a provisioning URL. I think this needs to be changed to: {if rps == "1"} # We still need to set the provisioning server static.auto_provision.server.url = {get http_scheme}{get http_host}/yealink-{mac}.cfg {elif https != "true" && model != "t38g" && provision_https == "true"} static.trusted_certificates.url = http://{get host}:{http-port}/yealink_cert.pem static.auto_provision.server.url = https://{get host}:{https-port}/yealink-{mac}.cfg {fi} so that the phones are able to keep updating as required. There is also this block that I assume would need to be updated to have the "static." {if mac != ""} auto_provision.server.username = {mac} auto_provision.server.password = {mac-hash} {fi} I have updated the template on my server to reflect this, however, would be nice for this to be the default so I can leave the default template in place when new updates come through.

Fixed up my silly typo. 6113xx... Is how it comes in from our trunks. I'll see if I can post some screenshots for you when I get into the office.

GregV's examples just touched on something that I have noticed for our inbound 1300 etc numbers. In Vodia we have had to enter these as 01300xxxxxx in order for Vodia to match the destination. As per Greg's example, we receive the number as 611300xxxxxx from our carrier. All other landline / local numbers work fine.

I have a couple of hunt groups setup, if no one answers they are set to go to an extensions mailbox. e.g: Is there a way that I can specify that I would like an alternate greeting to be played by the mailbox when it is reached from a specific hunt group. For example, I have a hunt group for sales and service which both go to the reception extension's mailbox. If someone calls sales they should hear a specific sales greeting, whereas someone calling support should hear a specific support greeting.

Guys the new documentation looks fantastic and super easy to use! Job well done! Love that will be able to see recently updated articles.

It would be great to see Vodia expand the speech to text functionality for voicemail transcriptions. In our previous system we migrated from we had the option to use Azure Speech to Text, since moving to Vodia and using the Google Speech to Text we have found that Google's service is no where near as accurate as Azure's for us. Is it possible to look at providing the option to use Azure (and potentially other services) at some point in the future? Preferably, this might even be a domain based setting, as dialects from different locations may be a better match for different speech to text engines.