Vodia PBX

Internally, recordings are triggered by an event like the call hits an extension that should be recorded. Because multiple events can trigger the recording, it results in multiple recordings—each of them with possibly different permissions to listen to them. For example lets say a call comes in, goes to a "VIP" A and gets recorded, then that VIP transfers the call to a "lesser" user B where recordings is also enabled: should the whole call recording be available to B? It's probably making things overly complicated, and it would be interesting how other systems in the past handled this problem.

First of all please make sure that the MAC address is ready for pairing/provisioning. In 69, you see some gentle blinking next to the MAC address in the device management page. As for the certificate, if you have an old firmware on the phone, it might not have the Lets Encrypt Root CA preloaded (unless you have your own certificate on the server). In that case, update the firmware first and try if it works. Otherwise you might have to proceed with HTTP and SIP/TCP.

It is S3. Yes, that is still TBD. We might just whitelist EC2/S3 for now. Every recording that is not on the system anymore is a good recording. Keep in mind that some call centers generate many GB of recordings every day.

The EC2 integration is not very well tested and there are also some glitches with the playback from the web front end because of the content policy, however this is how we are using it right now. Once we have added this, we'll add this to the web front end to make it easier to set the values: record_location: ec2://vodia-test-recordings/$*.wav cloud_providers: {"ec2":{"provider":"amazon","AWSAccessKeyId":"AKIAQAD3PM5NTG7CYT6C","AWSSecretAccessKey":"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","AWSRegion":"us-east-1"}} Setting this up on Amazon is a science in itself, especially granting the right permissions. We'll probably have to do a whole webinar about that.

For the queue, there are two types of calls that did not connect: When an agent did not pick up the phone within so-and-so many seconds, the PBX considers this a "missed" call—by the agent. When the caller hangs up before the call connected after so-and-so many seconds, this is considered an "abandoned" call—for the queue. We are trying to streamline the wording in the various texts in email and the web front end; it is not always consistent.

If you click on the call history entry you see the details:

Most of the work right now is on 69 so that everything works better than in 68. Some of the work is easy to port back to 68 and we happily do that, but obviously we don't want to rock the boat on 68.

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.