Vodia PBX

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?

As you might have seen in the release notes, there is a new setting for groups. With the luxury of hindsight, we should have automatically added a default group right from the beginning; but we don't want to break things in a 30-to-32 upgrade by suddenly changing the behavior. Thus the setting to explicitly turn it on. I would give this a slight chance that it resolves the issue about specifying which user can see what recording. But obviously we need to set up a test environment where we can see this on 68.

Ok 68.0.32 is available for download now.

There were some issues with groups and selecting specific extensions. IMHO it should be possible to narrow the scope of who can see what recordings in 68. There will be 68.0.32 shortly with the specific extension selection working, and that might also resolve this issue.

I don't think you can use websocket but we can take a look how much work it would be to add it as integration. How popular is it?