Vodia PBX

Right. The idea is that there is this office space where people come and go and just grab a desk in the morning. Each desk has a VoIP phone, and that phone is just waiting for someone to grab it and log in (there is an option for the tenant to reset the hot desk at midnight for those who forget to log out). You can also set the hot desk from the PC app, so that you can enjoy the usually better audio quality on a VoIP phone (setting the hot desk might be a feature that also finds its way into the mobile apps).

Looks like the check for the hot desking destination number went back and forth. Hopefully the next build has it right—after all.

DTMF is a longer story than it might seem at first glance. Do you remember on which device you were using it? The support for DTMF depends on the browser which is frustrating considering its such a core feature of a phone call, and we had to implement a workaround so that at least when in a PBX IVR you can still use it.

Hmm this all looks good. Don't be fooled by the PCAP traces on the PBX, they are always decrypted because otherwise we would not be able to hear anything. You could double check from the phones built-in PCAP.

At this point I would say clearing the ANI is okay if there is a domain ANI.

Well that would indeed be a problem. Anything in the logs? The setup is for offices where you simply sit on another desk every time you come in. It's becoming a part of modern work culture in some industries. I agree a lot of the calls will happen through the PC and mobile phones (e.g. using the Vodia app if they can use it on their private devices), but we see the demand for a piece of plastic on the desk like a big screen that workers can use on that day. Emergency must be possible any time, and regular calls after logging in.

Just wondering if we are breaking anything if we allow the user to clear the ANI. E.g. what is there is no default ANI? Then we have a star code for creating a hard-to-find support ticket.

Well the question is what you want to reset it to? Also in most of the cases there is a pool of ANI numbers to choose from. The front end shows the numbers in the dropdown (even 68 should do that), where this is a million times easier for the user than dialing *59 numbers.

This is a fallback mode for explicitly settings the possible variables for the Fanvil devices. You set the values in the parameter, separated by semicolons and name=value pairs. Available names are type, value, title and icon. For example type=4;value=1234 would program the button to use DTMF and send the keys 1, 2, 3 and 4. This avoids having to change the template to arrange special button modes. What modes are available is on the Fanvil documentation site, the PBX just passes it through. It will be in the next 68 build.

We have fixed an issue with as-feature-event and DND on hot desk that seems to have affected the ability to set DND from the VoIP phone—without hot desk. This should be fixed in the latest 69.0.5 and the next release then.

We had some support for HID devices also in version 68, however it was totally differently structured. At this point we have to plans to port the HID code back to 68.

If you like try the version 69.0.5. We will work on documentation, but for now put into the "Username or account" your WhatsApp Phone number ID, some random "Application token" (for verification with WhatsApp) and the "Application secret" the access token from your WhatsApp app. You must put something into the "Address for pulling MMS content", e.g. your server address (must be https as fas as we can see). This version supports inbound and outbound text and images.

Its all too familiar when in doubt, its the firewall!

Seems like a glitch for the Polycom phones that has not been found in the past ten years or so. We'll fix it in the next release. Until then you can just use the star code.

The next build has a flag on the welcome page where they can decide to suppress the passkey topic until they explicitly enable it again. This should really keep annoyance to a minimum. We recently see that a lot. It's because scanners are jumping on anything that looks like it would provision Yealink phones and hand out a password. You can disable it with the setting "Automatically list unassigned MAC addresses" in the "Phone Settings", and that would be another setting that should be off by default when deploying a hosted PBX (it makes mostly sense in LAN deployments). We had previous attacks where the scanner went through the whole MAC address range of the Yealink phones. This is why the list is limited to max 256 devices. The fact that the phone is listed there does not mean that the PBX sends anything useful to the scanner. Well its another classic... I know it happens to me as well again and again until I realized that my IP address was blocked. What else should the PBX do? Show a message "you are on a blocked IP address"? In what language? The PBX obviously wants to keep real attackers away from the PBX and essentially pretend to be dead, or at least provide as little information to a potentially hostile client. At this point, experience will turn those 20 minutes into maybe 20 seconds...

Those who are using the PBX for many years are so used to the name "domain" they are wondering why its now tenant: Because it's multi-tenant. Its marketing. The term "tenant" became popular far after release 1.0, and we eventually had to adjust to reality and go through the painful process of renaming the domain into tenant. It's similar with the "name" of the tenant. If you look e.g. on Microsoft Exchange and how they show their tenants, they also use "names" which are really just a descriptive string, which provides more freedom to the ones setting them up. DNS addresses are a subset, and of course you can choose a name which is the same like the DNS address. Ideally, you never have to enter the DNS address manually and get there by clicking on it. Maybe we can just add the DNS address somewhere in the tenant web front end, so that there is no need to navigate back to system level to see it.

Hmm. I am sure it did work at some point, however Yealink used to have the problem that the SIP TLS did not include the TLS/SNI extension which is a problem for multi-tenancy. But if SIP/TLS works, I would not see any problem negotiation the SRTP/SDES keys.

Total agreement on minimizing support. We want to offer a lot of functionality, and that is in conflict with the goal of minimizing support. For example, one time killer is the onboarding of users. This is why we have been working on the logon experience without passwords, because passwords are not only a huge security problem but also cost a lot of time for admins as well as the users themselves (hacked systems are an extreme example of lost time spent on fixing everything). At the risk of being on the leading edge we decided to use passkeys instead of 2nd factor, and we believe that soon this will be mainstream and we don't have to educate users any more. Other topics are more tricky. For example, we have added many features for LAN provisioning that look outdated today. Should we silently drop them? Or set the defaults so that the LAN deployment becomes the one that requires extra work? We have started to add some hints like changing ports but not actually doing it. Should we by default set he "IP routing list" to "private public"? The answer might lie in providing VM snapshots where everything is setup already, like for Amazon EC2. But even there, you still need to get a DNS domain for the tenant, the Amazon EC2 address will not work with Lets Encrypt. We had a lot of problems with admins using the same DNS address for the whole server as for one of the tenants, and hopefully have that sorted out in the latest builds. "Make everything as simple as possible, but not simpler" (Albert Einstein) might be the right motto.

The template icon is just an indicator. But maybe it makes sense to make that a link to the actual profile.

The PBX SIP subsystem is aware about multiple network interfaces. In a nutshell, when the PBX sends out a packet it figures out what IP address the operating system would use when sending out the packet and then puts that into the SIP/SDP message. The mechanism can be explicitly overridden by the setting for the "IP routing list". But if the operating system is configures correctly, it is all automatic. This works with IPv4, IPv6, VLAN, VPN, SD-WAN, LAN and whatever is out there. It does not matter if there are single or multiple physical addresses. Vodia IOP happens to have one physical port, but in Linux you can put many network interfaces on it. If you have a server with multiple NIC it does not make a difference for the PBX. Problems are mostly because of NAT, either because the SIP trunk does not use a SBC or because you want to connect users home. But if possible I would prefer to set the routing up properly on OS level and then it will be working out of the box.

If you like, try 68.0.5 (daily build). Poly Edge B will be a challenge because it's a completely different phone. The Poly Edge E series is a lot easier—it's practically just a renamed user-agent.

I would still say this is something the address book can do, also for a queue.

We'll try to suppress it in the next build.

We are trying to get updated MacOS and Windows apps into the stores—but it takes longer than expected.

Other providers are also starting to use OPTIONS, for example Amazon Chime is using OPTIONS. It seems to become "fashion", maybe just to make it very hard to register a VoIP phone there to keep pesky consumers out .