Vodia PBX

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.

Shared lines are still popular for people coming from key systems. We added a feature that lets the ring group look like a shared line — its easy to try out.

There was a problem with startup when old conference schedules were in the pipeline. The PBX would not start then, this fix could not wait for a 68.0.8 version.

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}