Vodia PBX

Yea we actually need a policy for that (also for the other apps). For example in public environments, this would be a problem because you are not allowed to delete anything.

There is an option for that in the queue settings, did you see that (Show post-call survey)? In the future we might add more stuff there, so we kept it under the term post-call survey.

You might have to retrovision the phones one more time. Fun fact is that while practically all of today's VoIP phones support SNI in TLS for HTTP, they don't do that by default for SIP and LDAP believe it or not. Some support enabling it, and for some we need to provision them in the way so that they will see the system management DNS address and not the tenant address as a dirty workaround.

In the FAX calls that we did for testing it was always the caller that hung up. But it seems that that is not always the case and we need to disconnect after the FAX has been received to be on the safe side. We will do another FAX round soon anyway, the ECM for "analog" is still missing and this would further enhance the reliability obviously.

Looks like you have turned on the translations in a previous version. In order to see the texts, you need to remove (or rename) the dict.json. The wrap up codes or categories are there for the agents to categorize calls, so that later analytics can better understand what the calls were about. For example, categories could be "winter tires", "summer tires", "repair", "accounting" and so on. The codes are reporting in the nightly emails and you can also download the call records in the queue management in the user front end — obviously need to have the permission to manage at least one queue for that.

Hmm actually not sure. There were some changes with the identification with the trunk, and that could have to do with Teams. I guess we'll find out! But I know that the net mask was causing a lot of erratic problems with Teams trunks that were set up versions ago when the associated IP addresses were a much smaller range. It was really just the label. The settings internally were not affected so that you don't have to change anything, it will just show on the front end the other way around and hopefully now makes sense.

We have made a 68.0.34 build with a couple of fixes that can be seen in the release notes. Nothing really spectacular, but a few annoyances that came up in the past few weeks. One of the major points is an improved Teams behavior, especially if you are using IPv6 for Teams please make sure that the associated addresses are up to date with the SIP trunk template.

Or this !7873$!100!

Well maybe we should just split the V68 Windows app from the V69 Windows app. Then we can just freeze the 68 app pretty much and don't have to deal with this when we add stuff to the V69 app.

Just changing the service flag would be relatively was (that's what the iOS app does). Monitoring with live updates is another story.

What if you call the seconds stage directly? Does it work then? I would say we are talking about 4 redirections, and that should not be a problem. I would look into the logs, there should be a clue why the voicemail does not work...

Well we have added stuff that at least removes accounts when they are deleted and renames them when their primary name changes. But its "hairy", there are a lot of references!

You can change the global settings in the reg_settings.htm page without the need to restart, including the variable that limits the number of redirections (if that's the problem).

Not ATM. In the mobile apps, users can change service flags.

You can change the values in pbx.xml conveniently through the reg_settings.htm page. There is an edit button in the header where you can select the setting that you want to set, no restart required.

It's actually different from what we have in 69, and in 68 it's labeled the wrong way (at least inconsistent with all the other places). We'll fix this in the next 68 build.

Did you try the "local override" (at least that is how it's called in Safari) in the browser? It's a very convenient way to change anything in your web page and it's great for tinkering with such things. E.g. if you are not happy with the numbers in your online banking account, try this method — does not require any changes on the backend and might impress people looking at it!

There were still some unrelated changes for 69.1.4, but we'll turn the switch today to make the 69.1.4 the version that will be shown on the upgrade page including ignoring the closing of the notification.

Well the reject is triggered when the Notification gets closed, see https://developer.mozilla.org/en-US/docs/Web/API/Notification/close_event. It seems it's not clear if this is because of a user interaction or because of the browser after a timeout closes the window. Looks like Electron has a different way of handling this than most of the browsers. Anyway, IMHO it is not worth the trouble. As a short-term measure let's just ignore that event (69.1.4). Then as the next step to clean this up, IMHO clicking on the notification should just bring the tab to the front and then the user can decide in the tab what to do — accept the call, reject the call, divert, and so on. Yes this will mean two clicks for the user, but because the browser notification essentially has only one action item available today, well that is what we have to work with. We are working on the next Windows store version that will handle notifications through the Windows API where multiple choices are possible and fit into the Windows user experience better than the browser does today. That will be. the ultimate answer to this annoying issue.

In the "redirection" area or in the "condition/parameter" area?!

Yes the new template uses 13.107.64.0/18 52.112.0.0/14 52.122.0.0/15 52.238.119.141/32 52.244.160.207/32 2603:1027::/48 2603:1037::/48 2603:1047::/48 2603:1057::/48 2603:1063::/39 2620:1ec:6::/48 2620:1ec:40::/42. This includes IPv6 addresses; it seems that Microsoft is not using them yet but it's only a question of time. This will remain some manual work because this is something that every customer can configure differently. The "may terminate" is important if the PBX should act as SBC, not just as PBX endpoint.

AFAIK the problem with the key file is that it can contain only one connection. IMHO sniffing SIP packets is increasingly useless because just about anything is getting encrypted these days (rightfully). It would make sense if the sngrep would be able to receive the master key somehow. I am pretty sure that VoIPmonitor (for which we have added the key logging) is also using OpenSSL or GnuTLS, so there must be a way to "leak" the key into the library.

The path in the file system then would be xxx/domain.com/ instead of xxx for the system. Generally I would prefer to use the REST API to upload changes that affect only one tenant. As for the DNS verification, if you are free to use any path, why don't you just use the tftp directory? For example you could put the file into https://customer.pbx.com/tftp/ms12345.txt. You don't have to enable reading from the file system at all for that.

The PBX has the option --key-log-address adr:port to tell sniffing tools what the TLS master key is. It then sends a UDP packet with the following content: {"cipher":"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","sessionid":"0123456789abcdef","mastersecret":"0123456789abcdef"} Is that something that sngrep could use as well?

I agree. Personally, I would probably write some bash/curl script that does the necessary changes. We don't do these changes usually for some reason. As for SRTP stuff, we figured that the relative number is still small (sadly) and we better get it done sooner than later. The old SRTP was simply not following the RFC, and it was better to fix this now.