Vodia PBX

The API documentation needs some TLC. The focus was on getting 69 out of the door, and we'll have to spend some time on explaining everything. For example, we have a beautiful article ready on passkeys that we will release in a few days.

Oops yes that rules that option out.

As you might have seen in the newsletter, version 69.0.0 is available. It is a release with many new features. This is exciting and makes sure we are keeping up with the many changes that are currently happening in the commutations technology space. After the release is before the release. We have already found a couple of smaller glitches in the new front end like from/to mixed up in missed chat message activity logs and we are already making daily builds with the name 69.0.1. Also, it seems that insecure login over HTTP causes problems with the latest Chrome browser which we are addressing. Another common problem is that administrators cannot log in because the system management DNS address was set to some bogus address on many servers. Well — its written in the release notes but it seems it is easily overlooked... We expect that it will take a few days and weeks until the dust has settled. We are working on making sure that everything is running smooth as soon as possible. If you find anything that should be corrected, please let use know, ideally in the form of a trouble ticket with steps that describe what the problem is and how to reproduce it. Underneath, we have made some great improvements that will make the PBX even more rock solid. We are excited about this new release and want to make sure that administrators and users see that we arrived in the year 2023!

With the groups, we could build something around there block calls permission for the other extensions. Alternatively you could make the extension a residential extension and block internal calls, however obviously then the calls must be routed outside of the PBX as PSTN numbers.

Good point. Both WebRTC and VoIP phone registrations are actually interesting, so we'll need essentially to keep both of them separate.

What is a KB?

In version 69, we have a framework for this, see https://doc.vodia.com/docs/integrations-framework. Even if they have their own CRM system, this should be able to address this properly.

Well it is definitively possible, the question is what is the easiest way to achieve this. First of all, I would make sure that the dial plan for those extensions limits the calls to the allowed numbers. Even if you are hiding elements, this will be still useful in case your students are smart and figure out what the API is doing underneath. As for the config, I think the best path could be to display:none everything in the custom CSS that you don't want to show. This would be relatively easy and should get you close where you want to be.

If you have a very old PBX, your list of Root CA must probably be outdated. Try navigating to Settings → Security → Certificates and click on the Reset button at the bottom of the page.

The next version (69) will have this.

There is currently no option for that. There are many ways to report CDR, however you'll have to set something outside of the PBX.

If you want to use your own images in the email you can just "hard" code a link (you can even put the files e.g. into the tufts directory of the PBX and have the PBX serve them). That applies for static content. For dynamic content, things get of course a lot more complicated, e.g. graphs. For that one, we are starting to use backend JavaScript which is an entirely new problem. However there is actually documentation about this.

There is currently no way to increase the history size. We would be worried about taking up too much memory! What you could do is to log the changes to the file system with the regular system log and then filter out the relevant messages.

Please make sure that your PBX has file system access permission and also your file system has enough space available for the PBX process. 1970 means that there is actually no (valid) timestamp, and the record is probably missing in the file system. Generally speaking if there is anything screwed up with the file system, chaos will break out. It is similar e.g. if files are missing or corrupted with for your MySQL database. You want to avoid that.

Ringback on the PBX is coming from RTP, and if you can hear RTP after picking up the call it is most likely a problem with your SIP trunk or a missing file in the audio_xx directory (ringback.wav). You can try if it works calling another extension.

As for LetsEncrypt there are two chains that they are using. As far as I remember the original tool chain will eventually be retired, but you could use the alternate LetsEncrypt chain. It's about old Android phones that cannot be updated, but as long as you don't use old Android phones maybe the alternate works better for you. Apart from that, maybe there is anything on the VVX log that would explain why it does not work? Or in the PBX log (TLS level 9)?

On Android, we are entering the phase when the call management is done by the operating system. I agree it's a little bit puzzling that Android does not seem to care which app was dialing the number, but that affects all apps not just the Vodia app. I guess time will tell if the next update of Android will address this issue. But as fas as I can tell, the app itself has no control over this.

The phone should obviously not loose the provisioning address. One typical reason is that the phone is in the LAN where a router overrides the address with option 66. If you are able to log into the web interface of the phone it should be possible what was set up and that might give you a clue where the address is coming from. Maybe it is still set up for cloud provisioning and the MAC address was not removed. That being said, if you can, it would be actually preferable to use the Poly remote redirection service and just point it to the PBX. TLS works only if you have a certificate that is accepted by the phone. If the firmware is recent, LetsEncrypt should work fine. You have to get the provisioning working, otherwise this will be an uphill battle. Poly phones (at least the models that we tested) don't use SNI for TLS, which requires that you put a server DNS address into the global settings otherwise it will not work.

One way to solve this problem is to use TLS. Then the ISP will have problems determining what is going on. If they still block UDP/RTP other services like WhatsApp will also not work and their support department must be either very busy or very ignorant.

We tried to reproduce this problem, but had no problems. What codec are you using? And what iPhone model?

We need to add some more real life examples, agreed!

There are some steps on https://doc.vodia.com/docs/vodia-io-wan along with some other articles regarding IO.

Well the underlying router platform has many possibilities, and I believe it could also do a bridge. However unless you want to use the physical LAN ports, you achieve the same effect by just connecting the devices directly to the firewall. The IO would then act like a regular PBX with just one network interface. IMHO that would be a very easy setup. Or do you need to use the physical LAN ports?

If the IO is supposed to be a DHCP client, the WAN port is your friend (even if you use a static IP instead of DHCP you should use the WAN port). The LAN ports are typically used when the IO is service as DHCP server. You need to make sure that the network in your LAN does not overlap with the address range in the Vodia IO (which is by default 192.168.0.0/24). Because the WAN was designed to be using a public IP address like with a typical router, you need to enable HTTP access on the WAN interface—the only way to do that is to use a LAN port, log in to the web interface, do your changes and then plug in the WAN port. You can also use the WiFi of the IO, e.g. if you have VoIP devices. And of course you can use the LAN ports for other VoIP devices, helping to isolate the VoIP network from the rest of the LAN, although it does not much more than just put it into a separate network.

I would also stay away from LDAP. It is just a very limited protocol, compared to REST. I would less use Wireshark and more the Inspector of the we browser of your choice, where you can see how the browser pulls the information from the PBX. Usually its easier to understand than even the best API documentation if you are familiar with JSON and the REST idea.