Vodia PBX

Would Russia, Samara (MSK+1) work? It is essentially Europe/Samara.

... and here we go with 1.20. OPUS was a great step forward, specially when there was packet loss it sounds so much better (please make sure that users have OPUS as their first priority if they have problems with audio quality). However with one step forward there was one step back, which could cause the app to crash early in the call which is obviously not helping with the audio quality. This should be fixed with the 1.20. Also we have added two more languages—if you are Spanish or Finnish native speaker and don't like a translation we'll be happy to fine tune the texts.

Hmm well you could send that extension a message to make sure that there is anything. The plus should only appear if there is a SMS provider available for the tenant, to make sure that users are not sending messages without the hope of getting the message actually out.

Might just be the form validation that stops you from entering alphanumeric. The Vodia API will take it. Anyhow that being said, we plan to move on to passkey in 69 instead of 2nd factor. The whole 2nd factor was just a workaround for a flawed system where users have to come up with more-or-less random passwords.

Thanks, we'll include that in the next build.

Yes it looks like access was denied. Did you use the auth token that you can fetch from the DM web interface?

You could put something {domain-param1}*{local-uri-number}@us-west-or.sip.flowroute.com in the request-URI header setting for the trunk. Then you can use the generic domain parameter for each tenant as the prefix.

Which timezone is wrong?

Well it should not sound metallic. What could be the problem is that there is some transcoding going on, e.g. the call comes in on G.722 and then has to be transcoded into OPUS. Quality never goes up with transcoding. If you can reproduce the problem, please generate a PCAP trace and attach it to a ticket so that we can take a look at it.

Well, there are many {} placeholders scattered for al sorts of uses. We generally try to show them when you turn the log levels up. As for the provisioning part, there is some documentation at https://doc.vodia.com/docs/phone-provisioning-variables that is a good staring point. That being said, if you can, tr to use the general parameters for the templates where ever possible, so that you will get template changes with the next software update.

We'll make a 68.0.25.beta at the end of the week if you want to try that one out.

Looks like we need to add telephone-event/48000 to the list of supported codecs... We'll do that in the next build.

It is probably because the client thinks that the 48 kHz of OPUS does not match the 8 kHz of the telephone-event. What device are you using?

On the top right of the text screen there should be a blue plus icon. For example, try texting into a page account it should be blasted out over the speakers.

We were waiting for Fanvil updates, especially for providing software update firmware links, but we did not get anywhere (frankly) and published the .24 version anyway. But obviously the Fanvil topic is still open. As for LDAP, we have had cases where the PBX was set to return thousands of LDAP results which the phone did not like; but at least the PBX did return search results. Also because older models require ASCII TXT files to configure and the newer ones use XML, there are differences in the LDAP configuration, so it would be good to know what devices and firmware versions we are looking at.

That was never resolving—it was always more like eye candy. I would stay away from SOAP and XML as far as you can and focus on REST instead.

We have released a new version of the app. There are two noteworthy improvements in this version. The first one is a better understandable icon. Users now see a handset, and they will understand that this app must have something to do with telephony. The second one is that we added support for the OPUS codec. IMHO that is a huge step, because this does not only mean that internal calls now can enjoy up to 48 kHz high fidelity; it also comes with a much better packet loss concealment which is part of OPUS. G711 is very bad with lost packets, and a lot of user frustration might just come from the stuttering audio when they have less than perfect internet connectivity. I would recommend trying to enable the OPUS codec on the PBX if you are on 68.0.20 or later, this should be a new experience for the iOS users.

For those who want to try the WP810/WP820/WP822/WP825 template, this should be in version 68.0.23.beta now. We did not have much time to test it, would be great to get some feedback...

The concept of a central routing resource was there since version 1 and I believe it was a good idea. It helps a lot to give the service flags understandable names like "Office hours" or "Extended office hours". What might be a good idea for one of the next versions would be an "inline" editing of those service flags e.g. inside the settings for the auto attendant, so that there is no need to juggle between the flag settings and the auto attendant.

Yea the problem is that world wide, there is no way around the space character inside a "human readable" phone number. So we have to get use something else (semicolon). Internally, its all +xxx.

You might be able to use SMSALA with the simple GET method already, as well as inbound SMS messages (see https://doc.vodia.com/docs/admin-messages). On their documentation site its not clear if they support MMS as well — if yes it might make sense to add them to the dropdown.

We'll make a 68.0.24 next week.

We do have some ideas in mind to take this to another level. For now, the main thing is to get the requests authenticated and then watch what the web front end is doing to get things done through the REST API. But I agree a proper documentation of all relevant functions would be more desirable. The current API web page sets high expectations but falls short delivering them.

There was a fix supposed to be in 68.0.22, however it seems that something with the branch did not work 100 %. You could try 68.0.23.beta or wait for 68.0.24.

The provisioning is based on the MAC address, and that works well for VoIP phones. For DECT, there is another identifier (the IMEI if I am correct) which is 12-digit hex code. Because we still need the MAC for the base station provisioning, the DECT handset ID was placed into the general purpose parameter, that is a "hack" — although just a small one.