Vodia PBX

There is no big point in using docker. If you want convenience, you might want to look into the EC2 image on the AWS market place. But if you want to spend one minute on the Linux command shell, just use the install.sh shell script. For docker the PBX is a "unusual" service. A typical docker container will just open one or two TCP server ports. However the PBX will open thousands of UDP ports, which requires a relatively large number of networking resources on the docker system. Because of this, it's easier to use a virtual machine or even a bare bone instead of a docker container.

A typical problem with the upgrade are unresolvable DNS management addresses (see https://doc.vodia.com/docs/release-notes-690). Another thing that is causing issues is that the new version is a lot more restrictive regarding sending sensitive content over unencrypted connections. I know it's a pain, but sooner or later entering a password in plain HTTP will be very hard anyway. The new version has a way to explicitly set the admin password with the options --admin-username and --admin-password. There is no more need to exit the pbx.xml file, which was inconvenient and—depending on the tool used—even dangerous. Also, you should make sure that the PBX can send emails out and that there are email addresses set for the accounts. The password recovery email can then be used—like with most web services today—to get access to your accounts.

Admittedly the 69 frontend turned out to be a bigger project than anticipated. But we are getting there. For example, it can now do things that were not available in 68, like dragging calls into the conference room and actually showing participants in the conference call, or allowing redirection while turning DND on for some time. Visual appearance is always debatable, but at least 69 is completely responsive and modular, which should give us happiness in the years to come and the screen resolutions to come.

If the carrier supports IPv6, you can just do that. All you need to do is add an IPv6 record. iOS and I think also Android prefers IPv6 today, so IPv4 and IPv6 can coexist. But even with CGNAT it should be working with the Vodia PBX SBC as long as the PBX runs on a public IPv4 address that can be resolved from the handset.

I would assume that all they are looking for is RTP content, which is relatively easy to spot by filtering for UDP packets with a certain header. It does not matter if the content is encrypted or not, the header looks the same. On the Vodia apps, we could think about changing the RTP packet signature to some random, proprietary format because we control both ends; however this will not work when we use standard SIP devices and software. The other interesting avenue could be to loo into RTP header compression (RFC 2508). Maybe the carriers just want to preserve bandwidth and apart from that have nothing against VoIP, and this could be a way to have everyone happy. Apart from that, there is almost no reason to use the standard port 5060. It just attracts scanners and creates unnecessary traffic.

There are NAT types that change the port if you send a packet to a different port on the same destination, though thinking about it this should not cause any issue because the PBX never changes the port. Luckily, the router industry has realized that VoIP is a reality today and have also improved their algorithms. Ultimately, WebRTC will pressure all manufacturers, and we don't have to worry about two-way audio any more. But until then it's a good idea to stay away from standard ports for VoIP, unfortunately.

Would the watch VoIP call work without the phone being in Bluetooth distance? I would doubt it. I would assume the watch is from audio point of view just a Bluetooth speaker device. I have also taken calls on the watch, but the audio quality is given the hardware far inferior to the phone itself. I do it if the phone is too far away, e.g. another room. I agree there are some cases where taking a VoIP call on the watch would make sense, but I would say something in the 1-5% area of all calls.

You don't need STUN for NAT traversal. The PBX SBC takes care about it. Yes the PBX in the beginning sends the packets to the "advertised" address, but as soon as the first RTP packet from the phone hits the PBX, it will change the destination and "learn" the real IP address. STUN may help to make this a little faster, but it can also make things complicated for certain NAT types. IMHO it is not worth the trouble.

One way audio is almost certainly a problem with the firewall if other offices and devices are working. You could try to use TLS so that the firewall cannot intercept the traffic. You could also ask the user to move the Yealink phone to another location (e.g. different office or home) to see if that makes a difference.

You would need a newer license key, please contact the sales person of your choice and they will give you one.

If only those users are affected and other users are okay, it is usually their Internet connectivity. I would turn the PCAP on for those users and take a look at the RTP. If the problem is only with a specific SIP trunk, then that SIP trunk provider might have a problem. But this happens almost never. If all users are affected, the problem is likely with the server. You can check if the server run out of RAM, which can happen sometimes. If a restart solves the problem, you might have not enough memory on the server. BTW 68.0.30 is available.

There was another post about it — we'll address this in version 69.

The ring tones should be loaded after the user logs in. After that they are just referenced in other words, if the admin changes them they need to reload them. So a "F5" should reload them.

Ok let try that in the next 69.0.3.

Not being against it, however in HTML how you want to achieve this? Placeholder will not work; title might be able to help when you hover over it. But it seems there is no easy way to show the name.

Nobody wants to be the first to try a new API plus its debatable if you want to talk to your clients through your watch.

... and everything just because of a space its ludicrous!

There was a miscalculation of the "ringing" time for the escalation (it seemed to be oaky for the redirection). We'll fix this in the next build. The waiting time seems to be okay.

That's right, currently it's only in the personal address book. However if the call came in through a group, it might make sense to assign the number to the shared address book. It would requite though that the one who is blocking the number also has the permission to manage the shared address book.

Is any other VoIP app using this? My favorite VoIP apps so far seem not to support calls on the watch.

I would first try from command line with curl and then when that is working use the GET method on the PBX.

Which models are missing there?

You can also dial *92 after a call.

The latest 69.0.3 contains a new graph right now only on the personal level that shows "availability" over the past 7 days. It consists of DND, registration availability (either though a registered phone or through the app) and actually being in a call. This should provide a good insight about staff working times, especially from home. One of the next steps would be including it in a weekly email to the user. The backend is pretty generic, 7 days could be a month or quarter and the term availability is also generic. At the moment we want to get this out of the door on an extension level, but we will soon move the also into the queue. The new frontend has a statistics section — what other graph would make sense? We can put the graphs that we have in the tenant administrator menu there easily and they might also help providing insights. One of the ideas is that 2020 it was about working from home, and in 2023 it is more about working from home and properly documenting it. We were thinking about measuring talk ratios (agent talking or caller talking) as an additional valuable insight, especially when compared with peers in the tenant.

Hmm. It would have to be all primary agents busy, otherwise it would get very hard to understand and maybe recursive. But there is a point about keeping the calls in the same queue. Queues are typically intended to process one caller at a time, similar to landing planes on a runway. That would imply that most of the time all agents are busy. This is why there was always this extensive music on hold for the waiting callers. Waited longer is supposed to look at the duration callers are waiting, essentially hearing music on hold; after hearing ringback is about callers hearing ringback because an agent is being alerted. These durations should be different. In most cases the waiting with music in several minutes while the waiting for the agent to pick up the call should be seconds. But when the waiting times are practically zero because calls are already redirected out of the queue these two conditions might look the same. Before jumping into adding a new condition IMHO we need to take a step back and see what we want to achieve here and if there is a better way that would fit the next few years, where the classical call center will definitively go through some more changes.