Vodia PBX

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.

Unfortunately, the number presentation in SIP trunks is a mess. The world would be easier if every SIP trunk just uses the format starting with the +. We even have some trunk providers that don't have the same format in the Request-URI and the From/To-headers! For outbound calls, there is a lot of control over the presentation by choosing the right headers. There is a large selection of variables in various formats to tweak it the right way. You can actually see them in the log when you turn TRUNK log to level 9. Then the number presentation setting of the trunk does not matter. For inbound calls, the trunk number presentation setting is important. There is some tolerance, e.g. as soon as the PBX knows that the number is in the NAPPA area it does not matter if the call comes in as 10-digit or 11-digit domestic number. We try to maintain the trunk list to handle this all without the admins having to worry too much about it. If you set up your own trunk provider, well, it does take some tweaking. We are glad to add other providers if you want to share your trunk settings.

The other idea would be that there is some timeout on the firewall. The user front end needs to keep a web socket open for receiving notifications from the PBX, and one hour sounds like a typical firewall timeout. The front end should retry though to establish a new connection after a few seconds.

Can you still check if there extension/tenant/system has "German" as the web language? Kind of hard to keep track of multiple topic posts. Its easier to have one problem per topic...

Thanks, we'll add it (also to version 68).

This problem was introduced with the video calling rework of the SDP handling. WebRTC is massively using SDP and with it comes a cleanup of the SDP parsing. Before 69, the PBX was tolerant (if not ignorant) with the media types, and RTP/AVP was seen as equivalent to RTP/SAVP. However it is not, and the tolerance could lead to static white noise. Now the PBX is more strict, and thus the trunks need explicitly be instructed to use RTP/SAVP. We are trying to figure out an automatic way to upgrade those trunks, but so far the manual change is the only way. The next build will at least have the templates for new trunks corrected.

There must be some place where the web language was set to "German", maybe because de is smaller than en (in sorting). If it affects only that one extension, please check the settings for that extension. If it affects the tenant, please check the settings for the tenant. Otherwise the system. The yealink_common template should show this: ####################################################################################### ## Language Settings ## ####################################################################################### lang.wui = {enum extension lang_web English cn=Chinese_S tr=Turkish pt=Portuguese sp=Spanish it=Italian fr=French ru=Russian de=German} lang.gui = {enum extension lang_web English cn=Chinese_S tr=Turkish pt=Portuguese sp=Spanish it=Italian fr=French ru=Russian de=German}

On system level, you see all MoH that are system-wide available including those that are visible only on certain tenants. In the tenant you will see only the ones that are assigned to the tenant. This is by design because only those can be edited and deleted. However the system-wide MoH can also be selected throughout the tenant.

Well... it is ringing. At least something! However I would try to set the ice: savp to explicitly turn on RTP/SAVP. You can do that in 69.1.2 in the trunk by switching to the text mode and edit the line there (we need to add it to the HTML page as well). Then it should be doing SRTP for outbound calls. Inbound calls are using SRTP properly?

In the latest 69.1.2 user front end, there is a new drop down item "groups" that shows more details and you can also select the date range. Then you can click on the download symbol to get this as CSV. Its currently for queues, but eventually we'll also have this for the ring groups.

Oh so there are a few things with TLS on 69. You need to set an additional parameter to tell it to use TLS: ice: savp Maybe you can attach the SIP INVITE and the response here (change the numbers to XXX) then this should become clear.

Can you verify its fixed in 68.0.33.beta?

We tested this here with Avaya J-series phones. After settings the maximum ring duration to ten minutes and the reprovisioning of the phones — it worked just as it should. Can you double check if the phones send any 4xx responses while they should continue to ring? Also, for Yealink phones, what happens if you set the following value to the Yealink General parameter and retrovision the phones? phone_setting.ringing_timeout=300

Can you try taking the Windows app out of the equation? There is a known problem with the Windows app. For example, does it work better if you use a standard VoIP phone?

Oh so for example if you call the mailbox from the phone it works? But a call to the trunk fails? Then it would be a good idea to take another look at the trunk headers. Maybe your current setup passes something from the phones to the trunk that the trunk does not like. I would 100 % turn on SIP call messages and dive into the headers.

Sounds to me like a random problem not really related to the release. Was the address blocked automatically? BTW in the 69.1.1 you can see the block history in the access page. Is there any other way you can check if the phone could send registration to the PBX?

Oh so you need a Windows build for the 68.0.33.beta? We made a Win64 version at http://portal.vodia.com/downloads/pbx/version-68.0.33.beta.xml.

I would turn on the logging for the SIP packets and see what the phones reply. If they disconnect the call then that would explain it. Plus there is a known problem with the Windows app that is disconnects the call after 15 seconds, a new release is in the making that will fix that.

What is your "maximum ring duration (s)" (/reg_settings.htm)? If the duration is 60 seconds, it will probably cause those problems. BTW if you add the same extensions in all those groups, they will continue ringing as if they were in one stage.

It's a lovely device, and it looks like it is using a similar configuration like the GRP models. We have added it to the 69.1.2 and 68.0.33.beta builds — it would be great if you can try if those templates work for you. As with all newer templates, there is a general parameter that you can use to add additional XML content, e.g. for volumes and other things that we don't want to change in the default template.

Look like an interesting device. Which model is that exactly? As a workaround for now, you can always just manually configure it. If there is just one or two, that might solve the problem. Alternatively, put the file into the tftp directory. Then the PBX will just fetch it from there. In the device, the configuration path would be something like http://pbx/tftp/your-file.xml. If you get it working we would love to add it...

There is no hardcoded limit. 1 MM records should be no big deal for a regular server, but you can also make to 2 MM or 10 MM if you like. It will just take up more space on the hard drive and also in RAM, though we try to keep the memory part small. Also it will make the restart slower because the PBX has to read the index files before it gets operational. For each tenant there is a retention period, which serves as additional limit. Typically the tenant limitation should be the one that really limits it. If you promise tenants to keep the records for a year then you want to make sure that the number of total records in the system is far more than you would expect from that tenant. Some Vodia partners have written external CDR storage solutions. For example the PBX can push records straight into MongoDB. However (at this point) it's a one-way ticket from the PBX point of view.

Its a moving target... We are trying to make it better in every version, but obviously it's hard not to trip over anything. Plus the phone vendors are also upgrading their firmware. But while VoIP phones seem to use SNI on HTTPS, it is mostly not enabled on SIPS. If they do, we are enabling it in the template. That was also a little bit of a learning curve. For prepaid licenses we are trying to ignore it, for postpaid the agent type is more than the Teams extension type. So the "all functions" would be the agent at this point. This was causing the problem that agents now includes Teams, which was causing a headache because of the inclusion of Teams in agent queues. Anyhow, as of 69.1.1 it should be working smooth. But we will eventually have to check if we still have to adjust this.