Vodia PBX

Even Linux kernels gave up on that one? Anyhow the 68.0.37 is good for production. For later builds, we just include the name beta in the build number to make it better understandable.

Did you try setting the "IP routing list" (in /reg_sipsettings.htm) to "public"?

There was an issue with the billing provider that caused the issue for certain kind of licenses (it essentially said the license was not paid and not just no answer). It should be back up again. Not sure if they had an issue with a leap year, or some underneath API change triggered a domino effect.

Should be available now.

At least right now, the templates are not linked to content with the user front end. You'll have to look at pbx-home.js. If you just want to change the HTML it should be actually relatively simple—all you would have to do is change the HTML content at the beginning of the JS file.

Yes we have moved the documentation to a new platform. Its work in progress.

Because now the calls are part of the chat history, a missed call is also visible in the chat history with the contact (if there is a chat history). Are you saying that the missed call messages are visible but not other text messages? Can you add a screenshot?

The firewall (hopefully) does not even have the chance to see the content. Nor does the OS make any difference. Not sure why my browser does not complain, but that might be something installation specific. I don't see a problem adding the data:, we'll patch the 69.2 with that (just the .dat file). We already used it in the dom_logo.htm where we need it to render the images.

We are in the process of releasing 69.2 can you try that version? There are still some warnings about some Google links, but there is not much we can do about that...

So the next iOS version will have the ability to delete chats. In the meantime, the workaround is to delete them from the web front end.

Did you check version 69?

I was not able to get it working with WhatsApp, seems 3CX is ahead of WhatsApp on the iWatch?

It's actually really a little confusing. The one settings comes from the requirement to keep the system from overloading (absolute number of CDR), and today I would say you can have more than a million records on a reasonable large system. The other requirements comes from the need for clients to retain records for so-and-so many weeks (or years). I would day if its really legally important to a client, you will not get around an external solution because its not about the storage itself, its also about other things like tampering.

Moving a tenant between versions will always be hairy. You could clone the server, then perform the upgrade, and then take the backup for the tenant and then move that backup to another server.

Well the PBX will not publish a SPF record... We initially also sent text views like 15 years ago, but it's a lot of double work and frankly this requirement is antiquated.

Hmm we preset provserv2 to us-device-scheduler.ymcs.yealink.com. I hope that that address does not blacklist requests from other regions? Seems like dmtcp.yealink.com is a better choice for now.

If GDMS does not work for you, you can also jut "manually" provision the HT devices. I would still recommend to use provisioning instead of completely manual configuration because of the small tweaks that make the device work better. On the PBX side, make sure that you have added the MAC and the Mac is ready for pairing. In the "advanced setting" set the "Config Server Path" to the address of the PBX (e.g. 192.168.1.2 or pbx.tenant.com) and select HTTP for "Upgrade Via".

Hmm yes if you backup your tenant and then restore it, it will be a problem because the way the data is stored is entirely differently. This will be difficult, its always better to stay with the same version with the .tar backup

Well it a long time since we have added that trunk type. At the time, it was on the "leading" edge, most PC did not even have a working speaker and microphone. Also the WebRTC specification has changed in some areas. In 69.2, we'll use more candidates, e.g. a mix of IPv4 and IPv6 addresses which will improve the likelihood that a two-way connection can be set up. When that is done, we can look into the WebRTC trunk plugin again.

There are some more changes coming for messages in 69.2, so that the PBX can automatically send answers and a tenant can have multiple SMS providers. We have documentation for WhatsApp, but it is not on the documentation portal (work in progress). This should also be available in the 69.2 build on tenant level.

There are currently still many changes happening in the user front end 69. The timeline is that we keep working on all sorts of features; however with the HTML element encapsulation there is some safety in making changes as long as they stay within those custom elements. The safest way to make changes right now is to work on the home screen (which is pretty empty anyway). There you have some inviting empty real estate that users will see after they log in.

Once a message has been sent to the recipient, there is no practical way of deleting it any more, especially on SMS. We all know the embarrassing "this message has been recalled by the sender" email that does not work. What does make sense is to hide the message, so that it does not clutter up the space. For internal messages, we can also think about editing the message, and there we can also show that the message has been edited by the sender to the recipient. It's not even sure if we need a policy for that; IMHO this makes sense in any case and this should work with regulations that do not allow deletion or alteration of content.

Generally, transcoding from one codec to another never improves the quality (unless you use some artificial intelligence magic). In other words, if your SIP trunk does only use G.711 there is no point using anything like OPUS. That being said, G.711 is bad when it comes to packet loss. Especially on mobile devices it makes sense to use OPUS even though the quality without packet loss might be slightly lower than with G.711 because in situations where the packet loss is high, users will hear a huge difference. In any case, I would recommend to stay from old codecs like G.722 or G.726 and even iLBC. In a nutshell its G.711 or OPUS today.

We'll have to spend some quality time with outbound calls as well. We have more or less quietly added a page for managing outbound numbers for outbound campaigns, but we need to work more on it e.g. a default wrap-up-code and statistics.

Yealink now runs the cloud provisioning server in different regions (e.g. GPDR so that the data is physically stored in the EU). In preparation for that, the PBX needs a new setting for the server URL. There was a problem that the PBX would not find the right trunk when there are multiple trunks associated with the same IP.