Vodia PBX

If you can, set up a Wireshark trace on your server (you can filter by IP address and port to keep it small). The question is if there is any TCP reset and who is sending it. It could be the firewall, but it could also be that the refresh traffic is slower than the TCP timeout. If its random, its probably not the firewall because it would enforce it always at the same time. Randomness could come from the lack of other traffic, e.g. call-related SIP traffic. It could even be something on OS level, e.g. in Linux there are parameters in the /proc/net on how long missing TCP traffic will be tolerated.

Many books have been written about this...

Looks like it's already fixed in 68, but we need to make a build.

Argh, yes it was not in the pbxctrl.dat file. We have generated a new 69.0.6 pbxctrl.dat one that includes it.

Today that would be considered a total no-go. There must be some kind of authentication. We currently have super-admin, system-admin, tenant-admin and user login types. Would it make sense to add another type just for the wallboard? E.g. we could recycle the tenant-admin, make a new type tenant-wallboard and allow only the wallboard to be shown. Then you could e.g. whitelist the address of the TV and choose a trivial password, write it on a post-it, stick it on the TV and it would still be reasonable secure.

In such cases it usually makes sense to generate a PCAP trace and check what IP addresses are being "advertised" by the PBX (or there is a codec mismatch). Typically it's a problem with the IP Routing List, e.g. try to set to private public that usually solves the problem.

You can also use 12:00p/sunday 11:00p/quarter 10:00p/month.

You can see all available variables in the log level 9 for the trunk. There may be some variables that are not reflected in the doc yet, and the point about logging it is to show what's available (it's probably easier than even reading the documentation). You can always "hard code" the other DNS address by just putting it into the header without a variable. But then obviously when you move that trunk into a different tenant, you would have to update it.

The announcement was quiet. It stores either in S3 or locally, but not both. We definitively don't want to surprise anybody with all recordings suddenly show up on some cloud storage.

The layout of extensions and other account types need indeed to be revisited. E.g. we could add another attribute to the groups that would tell the front end to put a specific group into the middle section of the screen.

The latest Android app now should have an option for managing the service flags, however it does that only for manual service flags (changing automatic service flags is not supported by the 68 API). And it does not automatically update the state, you would have to refresh it. That's a glitch we'll address in the next app version.

Well we quietly added it to the 69.0.6 build. However I am sure we will find a couple of issues that need to be addressed.

The checkbox is just to avoid the nuisance of having to click away the passkey dialog every time the user logs in. In theory you could edit the welcome page, but taking out a great security enhancement because of convenience sounds not like a good idea to me.

We have released a new build for 69, release notes are at https://doc.vodia.com/docs/releasenotes690. There are many things that have been fixed, but also we have fine tuned a few things that turned out to be pain points when upgrading to 69: Obviously a lot of administrators are using different URL than sys_adr to log in. The PBX now allows that again as long as there is no name conflict with the admin account name. We also added a checkbox for those that explicitly do want or do not want to use passkeys. At the risk on being on the leading edge, we still believe it's the way forward and in a year or so we will laugh about the question wether or not to use passkeys. But in some environments it makes sense to disable them and not have that pop-up come up all the time. The automatic assignment of queue agent account types was another pain point that hopefully should be working under the hood depending on the license type without further pain. We have also added a callback list view to the queues in the user front end. Of course you are welcome to use it, however this is an area we will continue to work on. It's fine for basic usage, but we have plans to make this more valuable and usable for typical outbound calling campaigns. Also if you are using the emergency call emails, please take a look at the new format especially if you automatically parse them. IMHO they contain better information and are now fully customizable, which we should have done like ten years ago. On the app front, we are working on updating them as well to make them work better with the latest versions while keeping them running with the previous versions. E.g. iOS 1.24 should work both with 68 and 69. Last, not least, please take the opportunity to check your backup policy before the upgrade. Take the opportunity to make a backup of your system just before the upgrade and you might also take a look into automatic snapshots. They have proven to be incredible valuable, and automatic backup has become so cheap.

I would dare to say that most of the installations will never use it. That's totally fine. It's for the "shared office" environment (aka WeWork, MindSpace, Regus, etc) or maybe for large companies that have huge downtown offices where you get another desk every day you decide to come in.

No worries. It's sometimes hard to get the "aha" moment! Being able to reproduce the problem is the hardest part. We already changed the logging for the post processing, not just to mention what parameters were removed during the filtering, but also what content. Hopefully this will help getting to the bottom of this one.

No—you can also call the hotdesk star code. But that's it: Emergency calls or logging in. We'll also remove the possibility to call the hot desking phone without anyone hot desking there in order to avoid further confusion. The hot desking account is really, really just for getting the actual user extension log into the phone and nothing else. IMHO hot desking extensions should no even have account numbers like 41, 42 or 43 and better call them hd-1, hd-2 and so on.

{post-process-yealink} writes a log message Filtering parameter xxx when it removes something (log level 9 for provisioning). The {parameter yealink-general} is in the header right after {require-credentials}. The replacement of the {lc} is already done at this step. It renders lines only when the text in front of the equal sign was not seen before, with a few exceptions like those URL parameters. I tested this here, and it did work as expected. If you have modified your yealink_common.txt please make sure that you have this structure: #!version:1.0.0.1 ## Model {get model} Version {get version} {if provisional == "true"} # ... stuff needed for LAN provisioning {else} {require-credentials} {parameter yealink-general} # ... all sorts of settings {fi} {post-process-yealink}

The main problem is that many implementations don't properly support the offer/answer model and are not able to handle multiple codecs in a single stream. For example when a device "advertises" that is supports G711A, G711U and G729A that means that it is okay to send either of those codecs, and switch between them any time without re-negotiation. And its totally okay to have different send and receive codecs. Unfortunately the reality is far from that, especially on trunk side. We have added several settings to deal with the situation, e.g. answer only with one codec ("present to be stupid") to an offer from a SIP trunk and have "symmetrical" codecs, so that sending and receiving are using the same codec. IMHO when it comes to problems on the trunk side, it is usually the best to just fix the trunk to G711U or G711A depending on the country and not leave any other choice to the trunk. Those "dumb" trunks transcode to G711 sooner or later anyway, so that the quality is actually the best if that codec is used in the first place and leave transcoding to the PBX. If you are using a trunk from the drop down, this might have been already setup and you don't have to tinker with the many settings. On the VoIP phone side it's usually not as bad. For the VoIP phones in a nutshell the phones should propose whatever they have, but the PBX makes the decision what codec to use. You can still fix the codec on an extension if you are using a phone that does not support RFC-compliant SDP codec negotiation.

I looked up Zabbix—seems like it would be worth showing how this works with the PBX! For example, fetching https://pbx/rest/system/config?name=license to make sure the license is not expiring. I know of people using Paessler and site24x7, and adding Zabbix would be great. The other point why the certificate is being renewed every time the PBX starts up might have been a glitch with the renewal process for the sys_adr address. We'll look into this in the next build.

We took it out from the Windows app for now. We'll have some work to do for the Windows app anyway, and then we can see if we can find a full-screen mode for the wallboard for the app that might also solve the issues e.g. when rebooting the PC (we all know the blue screen at the airport and we don't want that ).

The way we envisioned the usage is that the user logs in using credentials, passkey or whatever and then navigate to the wallboard, disables the screen saver on the OS, puts it on full-screen. The wallboard has a special way of keeping the session token so that if the PBX would have to restart or the connection gets lost, it would stay on the wallboard. This should work for a long time. This would assume that the underlying PC never shuts down. Passwords in URL are a bad idea, see e.g. https://www.politico.eu/article/dutch-reporter-hacked-eu-council-interview/ especially when they are visible to a lot of people! The question is what happens if you reboot the PC underneath, e.g. because it lost power or a software update triggered a restart. ATM it would mean that the user would have to log in again.

cert = certificate? Where? A new LE certificate?

Well, the whole point is to post-process what has been generated. Yes you can think about post-post-processed content , but IMHO the post-processing does everything you need and there should be no reason to edit the template if you just want to add or override a setting.

If you can, include the ^ in the pattern, otherwise you'll get random matches for example when the number 2121205123 would match 1205. The other question is what pattern is send into the pattern matcher. E.g. does the provider send it in the +-format? It would be great, because then you don't have to worry about the beginning of the number. ERE are powerful, but for humans hard to understand at times. You could play with the ChatGPT to come up with patterns...