Vodia PBX

Do you have a NOTIFY of what the UCM is sending? Maybe we can spot the difference.

Yes the phone needs to be registered to the PBX in order to have control over that phone. That is what the hot desking account is for. It might be better to use a name like "hotdesk-107" because nobody is supposed to call this extension or from that extension. IMHO there must be something else confusing going on, maybe a redirect all or multiple device registrations. In any way, hot desking makes only sense in specific setups. For a regular office where users have their own phone, there is no need for hot desking and hot desking accounts.

After logging into hot desking, please double check in the users account (not the VoIP phone on the hot desk) that there is the hot desking at ... set to the hot desk phone. Same after logging out, then it should be clear. And in order to avoid confusion (maybe from previous tests) that the VoIP phone itself is not hot desking anywhere else.

Looking at https://firmware.grandstream.com/Release_Note_GRP261x_1.0.9.83.pdf I would not see changes between 1.0.7.33 and the next one 1.0.9.22

It's at http://portal.vodia.com/downloads/pbx/version-69.0.5.xml keep in mind it is not a release yet.

Well I assume that Poly(com)/HP interest in providing an updated firmware is limited. If I remember correctly you can import the certificate through the phone web interface? I also remember that over HTTP we would provision the root CA into the phone, but that does not seem to happen? On a side note, you should also consider making TLS1.2 the minimum version, unless you are using really old equipment.

Extended regular expressions are used in many places, e.g. see https://en.wikibooks.org/wiki/Regular_Expressions/POSIX-Extended_Regular_Expressions for general information. Character classes are sot supported.

I think the way you use the square brackets does not work. E.g. instead of !^([(205|251)]{3}[0-9]*)!100!f! try !^(205|251)[0-9]*!100!f!

Anyhow, the PBX post-processes the Yealink provisioning files anyway. If there was an enterprise or site-ID, it will be dropped from the file.

That one seems to be a major pain point. We tried to provide some hints in the release notes, but the main problem seems to be that from older installations the system management DNS address contains leftover garbage which is now actually checked against the URL in the browser. It would be convenient to continue ignoring it, however it is a great way to fend off robots and it also helps generating the right SSL certificate, so we are a little stubborn about it and continue insisting that admins should log in with the right URL. We assumed that users don't do this all the time and it now in the settings (preferences). We even had cases where users did not know what button they are pushing and complained that they cannot make calls any more. Ok you would have to reject the call first and then click on the account image (top right) and there turn DND on. Three clicks... Internal messages are always possible. FAX depends on the SIP trunk provider but I dare to say that it works more or less with all of them today. But we might have to look into text drop downs when there is no SMS provider.

In Yealink provisioning world, the first occurrence of a setting wins. So it should be okay if parameters show up in the Yealink general and then again later in the provisioning file again.

100 %. There were some builds where that did not work as it should but that is as it should work. We are contemplating changing the way it works to reassigning MAC addresses instead of hijacking the registration. This might also help addressing the problem that button profiles need to be linked to devices and not to extensions. However before starting a new adventure, we want to have a release where the hotdesk in is just working as it should.

The PBX already supports stereo recording, with each party staying in their own channel. MP4 is a video format, MP3 could make sense but OPUS would be a better choice today. However its a mess what plays on the web browser, and at this point we'd rather not touch it. That being said maybe it's time to ditch the GSM codec as recording format. And going forward we will have to feed the audio into speech recognition, which further limits our choice for audio formats (uncompressed audio always works). The permissions are not only all or nothing—you can listen to your own calls but to all calls one with the permission. I agree recording multiple tracks is a waste of recordings and confusing. A possible way out would be to keep track of the involved users in the recording in the metadata, and allow the playback only if there is either only that one extension involved or the extension has permission to listen to all recordings.

If you are using automatic provisioning, assign the MAC of the device to two extensions.

Thanks, great suggestions. We'll add an enterprise and site ID parameter to the next version and also provide the tone country for a better local experience so you don't have to do that. We recommend to use the Yealink General parameter so that you don't have to customize (and freeze) the yealink_common template.

Cloud storage including EC2/S3 is powerful. We are just scratching the surface. For example, we could add additional tags that can be used in search—then there is no need to include those tags in the WAV itself. The way it works right now that the recording is held in memory until it is uploaded. I doubt that we can hold recordings for the whole day, this would obviously exceed memory capacity. But an outage of EC2/S3 for the whole day would be quite an event, and there might be bigger problems that the PBX losing recordings. I was not even aware about S3 being a standard but if that's the case it should be relatively easy to send the recording a different direction.

This is a very good point. We do have the plan to fill up the Home Screen with gadgets over time, but that has not happened yet and it indeed looks empty. This would explain why people have the feeling it is not finished. We had the same problem with the chat screen, where we put a background wallpaper like most chat tools do today anyway. As a quick-fix, we'll use that same background also on the Home Screen. Putting something like the welcome screen image there IMHO would be too heavy. Putting something there like the call history is helping only when the user has started using the user front end, which might be too late for the first impression. We have started working on that.

IMHO that's okay, maybe even a feature. Someone grabbing a desk in the morning would otherwise easily forget to login (or don't care), and then assigning the records to that user will be impossible. And people would call that person back on the hot desk extension, just to find out that the next day that person has changed the number—again!

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.