Vodia PBX

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.

To rule out problems with the trunk, you could try an internal call. If internal calls work, it is probably a problem with the trunk. E.g. many have problems with different codecs for send/recv, or they get confused if the SDP answer shows more than one codes. You then could try to set "lock codec during conversation" and "number of codecs in SDP answer" to 1. If internal calls are not working, and you have already forced OPUS for the extension, well it would be weird.

We are adding more and more managerial tasks to the front end, e.g. now you can upload the callback list through the front end. Or you can now clear wakeup calls through the front end for other users. But there is still a lot to do.

As for video conferencing, it mostly comes with email. Microsoft Office 365 and Google G-Suite cover a huge part of the market, and it comes with video conferencing. There are niches where that is not possible or their solution does not fit. This is the area where Zoom, WebEx and others are filling gaps. Then what is left over from that market is getting really special. Out of that remaining piece of the market, Jitsi is absolutely an option. You can search for "Jitsi hosting" on how to get videoconferencing service if all the other options are not for you. In order to compete in this market, Vodia would have to deliver true miracles to offer a better solution and there would be very little room to generate any meaningful revenue. Video calls are a different topic. As the work from home topic evolves, we do see more and more demands for internal calls with video. We don't want to get into the discussion of how transparent work from home needs to be, but we do see the demand for a tool that makes it possible. The point about internal calls is that there is no scheduling necessary, it's just picking up the handset and dial, hold the call, and transfer it if you have to. We have some internal video calling capabilities already, but we need to take this to the next level where all internal calls from apps and VoIP phones can have a video stream. Call recording is still a necessity, though we are trying to understand in what format we can deliver video call recordings in a meaningful way.

Hmm we probably have to dig out that headset and start using it again. It's been a while! But its perfectly okay to use it.

Did you try to set the codec in the extension settings tab for "registration"? If that user uses only the mobile app, it should be fine to force it to OPUS (select only one codec to force it). The PBX will translate between the codec and the mobile app.