Vodia PBX

As for the emergency we are about to release 69.2.2 where this seems to have been resolved. Also, we'll have a review of the Windows app coming up this week where wie will look into the tel-scheme issue and why this seems to be so hard.

We want to use OPUS for the mobile users because it just sounds better, especially when there is a lot of packet loss. But G711 is still the predominant reality in the world of SIP trunks. I. would say if it works, keep it on G711 but true happiness will require that we have OPUS on mobile devices. In any way, I would try to keep a PCAP for analysis reasons to see why there was one way audio.

Do you see the file pbxctrl and pbxctrl.dat in the /pbx directory? What if you mkdir /pbx cd /pbx ./install-mini3.sh

The screenshot shows the right location. If you don't put the polling address there, it will use the address that it learns when it checks the license server which includes the IP address from where the request was coming from. So if the IP address does not change, you should be good. If the calls connect properly thats a sign that the signaling works. You can take a look at the SIP call messages and the SDP attachments. if they contain the public IP address, the PBX is doing it right and then the question is if the ports are properly exposed. You can try turning on PCAP for an extension and e.g. call the mailbox with *97 and then check the RTP in the PCAP.

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.