GavinJ

This was exactly what I was after, Thanks I do have one potential feature request/improvement, which would be if you could dial *80XXX*YYYYYY Where XXX was the hunt group and YYYYYY was the number to forward to so that it could be set in one go. Would be useful to have these registered as speed dials for quick access from a handset.

When the toggle to allow an agent to divert incoming calls is selected, how does an agent actually setup an incoming call diversion for the hunt group?

Yeah, this was on a VoIP phone. Maybe it could be a toggle in the tenancies Voicemail settings? I would imagine that it would be the type of setting that a customer would want on all phones or not at all. The caller-ID could also potentially be prefixed with "VM (X/Y)", with X/y representing message # of total. P.S. Some transcription in the web app would be pretty cool though. P.S.S. I've also just done some research into Yealink's XML browser stuff, so I'm going down a bit of a rabbit hole there too now.

Is it possible to show the caller's number on the handset display during voicemail playback? If not, is this a feature that could be looked at in the future?

Double checked and that field is empty.

Has anything changed in 67.0.6 regarding call parking reminders? Specifically, one of my customers is having parked calls come through to their mobile after the call park reminder times out. However, all the settings for calling the mobile are turned off. Is there another setting I should be looking at, we don't necessarily want to remove the mobile number from the extension as they do use the *00 code to call the linked mobile. We only updated yesterday to 67.0.6 and have not heard anything like this happening previously.

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.