Vodia PBX

No problem. Right now we do these roadmap discussions in 1:1 meetings which are very productive. However we might need to schedule a different format which is more for the public, e.g. a webinar or some pre-release notes.

There is a roadmap and there are no big surprises on it, however this is not the right format to discuss it.

The # key is generally seen as confirmation key. In the auto attendant, it is also used for triggering timeouts (as if the user has pressed the enter key after nothing happens). In theory you might be able to use it in the direct destination area, but it would not read out the prompt to repeat the options.

Still a mystery. Can you private message the path to the welcome.htm?

As a workaround for now, you can just blind transfer the call through the pop-up on the call.

The thing is that it seems to work in our environments without the data... Anything in the inspector regarding code that does not come from the PBX?

Yes an obvious fix would be to add blob: to it (or data?). However it should not use data. I am wondering what is triggering it to use data... It should not do that unless there are some obscure libraries at work...

Are you running some kind of plugin or service worker that would change the source for the font?! The Content-Security-Policy should have font-src 'self' https://fonts.gstatic.com/.

Well you can attempt to do this manually — replace the pbxctrl and pbxctrl.dat with the ones mentioned in the XML. Don't forget to grand execute permission to the PBX executable.

No that was introduced later.

I would check the filesystem — did the timestamps of the pbxctrl and pbxctrl.dat show the date of the update? Then you can run ./pbxctrl --version to check if the executable is actually right. ... and this is a great opportunity to make a backup.

Looking at https://en.wikipedia.org/wiki/Telephone_numbers_in_Australia would it be safe to say that the PBX should return '+61' + number for anything that starts with "1" as long as the number is more than 5 digits?

The thing is that the PBX does not pass security scans unless it supports RFC 5746. There is a vulnerability for MiM attacks that RFC 5746 resolves. I would be surprised that this would pose a problem for Bria, as practically all servers that use TLS support this RFC. Anyhow, maybe someone can pas a PCAP to us so that we can take a look what is going on. On a side note, we are starting to replace LE RSA certificates with ECDH certificates, which might also be worth testing e.g. with Bria.

68 and 69 have diverged too much for that.

That is actually a good point. Why not having an error page — it might show the same content like now but should be customizable. The main concern here are robots trying the PBX out, and we want to provide as little information as possible and as little overhead as possible as well.

We have worked on the whole codec topic in 69.0.7 (not released yet). Maybe you want to give it a try. If you are using iOS you'll need a new app version to have it working with all codecs.

The question is where. We had the registration in the status in the early years, however when you have two registrations and then one drops out, does that count? What if you have a redirection? Or cell phone twinning? Also, then with the wake upper the apps, the mobile app is usually not registered anyway. The definition of registration is hard to come by in the mobile world or at least does not provide much useful information.

How about pattern 07xxxxxxxx and replacement 617xxxxxxxx? Anyhow, IMHO numbers today should be like you would enter them on your cell phone. This is what everybody understands. Be careful with prefixes when it comes to emergency numbers. When someone dials 911 (in the USA) they must reach the emergency service, without any prefix.

Some of our partners are using Acrobits, and we have no issue with it. However it's hard to implement features like uploading profile images through the standard SIP protocol.

The problem is that some tenants want to use different SMS providers. When the dust has settled after 69, we need to take another look and structure the SMS like SIP trunks, so that you can have as many as you like and they can be shared globally.

We are not aware of anyone using this except for poking around?

Well the Vodia LDAP server really does not support these options. Why not just use the LDAP settings e.g. like in Yealink?

Can you check the settings in reg_domains.htm for the domain for SMS? There must be something that makes the system believe it's a different provider.

Not aware of changes. Maybe the logging timed out? Try to set it e.g. to 24 hours (different from what it was before). There should be something in the log, SMS or not.

Anything in the log for LDAP?