Vodia PBX

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?

We are still on 68.0.31.beta, 68.0.32 is not out yet. We are waiting for feedback on two issues and then we should be ready to go for 68.0.32.

The PBX has to convert G.711 to linear because most browsers don't play G.711. That happens on the fly.

I am afraid this might actually be a pragmatic solution. Maybe someone should dig out the original decision to favor UDP for SIP — who knows maybe Henning Schulzrinne & Co hat the connection stability actually in mind. I am not aware anyone using DTLS for adding security, but that might be the next step. All that said, UDP connections are also not necessarily stable, depending on the behavior of the firewall. When the port changes on the NAT bindings, you'll have the same short window where inbound calls will bounce (unless the firewall keeps both ports open during that time, which I doubt). Firewall manufacturers could care more about VoIP and what a persistent connection means. Especially the manufacturers that don't have the slightest clue about and/or interest in SIP and their interference does not add anything in terms of security.

In 69 you can click on "forgot password" and then use your email address to reset the password. This works also for admin accounts in 69.

Well right now they are dialing into the system then punch in the zone? Some VoIP phones support a DTMF button mode where you could put this on a button.

Thanks for the investigation, it's quite interesting not only for the Vodia PBX but generally on how to keep 24/7 up. For me, the bottom line is that we will never be able to achieve 100 % connectivity with a client and there will always be spots in availability. It's the case for SIP trunk clients, but it's also true for VoIP phones. For VoIP phones, it's probably just a generally fact that they have their ups and downs when working from home and nobody complains. It would be possible to address this with the OPTIONS architecture where the UAC initiates a connection and the UAS receives it, depending on the call direction. And maybe in situations where inbound calls are very critical, this should be the preferred setup. But even there we will still have the problem that the clients also have their time when they are offline, and calls would still not connect. I would dare to say, that those VoIP client spots are much more significant that the connection between the PBX and a SIP trunk (it would be interesting to have some real numbers). What speaks for the SIP trunk TCP/TLS connection is that it is easy to setup, it can be secure, the stability is probably better than with the VoIP phone connection when working from home and maybe one more thing to keep in mind: The PBX can report the availability, e.g. through emails when the trunk status changes. That is a lot harder when using UDP or TCP/TLS with OPTIONS where it might be very hard to find out when the trunk is actually down.

... probably because of the midnight check. Anyhow, next build will make this easier (to understand as well).

When deleting the certificate, well getting it back is not easy in the current version. The reason was that the operation was essentially done every day and this caused a lot of unnecessary cert activity. Anyhow, in the next build the PBX will request a new certificate if you change the addresses for the tenant.

That probably means that there is another process listening on that socket. You can use netstat to see which processes are there. The --config just gives you the option to use a different file than the pbx.xml.

Can you paste the exact phrase, so that we can match this with the code? But it does attempt to fetch a certificate? You can also turn on the logging for the web client to see the traffic between the PBX and the LE cert bot. Is there anything?

Hmm which command is prompting for the region? The script installs some additional software, but you can as well just skip that part of the installation. E.g. the PBX now downloads missing audio files automatically.

The certificates live outside the tenant, and that means that they are not part of the backup. Admittedly, that's debatable but it makes sense if you choose a different name for the tenant later. The Lets Encrypt certificates should eventually show up, especially if you trigger a name change. When you create a new tenant, it may take a minute before thats the case. There is a ACME (thats actually the name of the protocol that Lets Encrypt uses) log level which will show you some progress messages when the update mechanism gets triggered.

Hmm so you can move from 69.0.6 to 68.0.30, but not from 69.0.6 to 68.0.31.beta? Maybe you can double check that the upgrades went through with the --version option from command line and also make sure that the .dat files match. As for the login, please make sure that the browser cache is not playing tricks on us, especially if the welcome.htm page was modified.

Hmm... You can check from the shell ./pbxctrl --version what version you are running. Also, you can check what time the .dat was updated. Maybe a file did not make it?

Of course. Maybe you have a test system somewhere. Anyway, the plan is to release 68.0.32 on Tuesday or Wednesday next week.

For me, the bottom line is that Microsoft and others choose to establish a new connection for incoming calls because they also found out that keeping a TCP connection alive for a long time is hard to achieve and it is more reliable to establish a new connection (possibly, retry if it does not work on first attempt). After all, browsers literally connect billions of times every hour and it works very reliable. The price for this is that the client cannot be hidden behind NAT. In other words, as far as I can see it, if you want to stay behind NAT and avoid manual setup of the PBX address, you will have to live with the fact that the connection drops from time to time for a short while and incoming calls will not make it. BTW the Teams clients are also living with that fact. I am pretty sure that if you watch their connection stability, it will also have their ups and downs. But it is limited to one extension, and not the whole organization.

If you can, try the 68.0.31.beta version which should have that "confusion" fixed. We'll make that a 68.0.32 soon.

The "SMS not enabled by default" is most likely the problem here. There was some confusion when SMS is enabled for the tenant between the versions. The log message suggest that is should be enabled looking at the settings, but, well, it does not seem to be enabled. Does it work if you enable it in the domain? We will make another 68 build where this should be working as one would expect.

Hmm why would the PCAP miss the FIN? Maybe some firewall in between did it? FIN (still, not being the expert) is not encrypted because its TCP not TLS.

It should not be normal... The FIN, ACK looks good to me (not being a huge TCP/IP expert), I guess the ACK is kind of preemptive. Anyhow the PBX sends the same ting back and that means the TCP connection is closed. Which raises the question what Telnyx (or, any provider) is doing to keep a TCP connection alive — for weeks, months, years. How do they do software updates? UDP is much easier in that respect, you would not see anything in the PCAP. Microsoft Teams is opening TCP connections in both ways, which does solve that problem: For an inbound call it opens a new TCP connection; however that approach has the disadvantage that the PBX needs to be on a public IP address. Maybe the time of disconnect is the price to pay for TLS with a device behind NAT.