Vodia PBX

This sounds like a problem that we had around a year ago — what version is that? Could you use something like a 68.0.26?

In the type from down for the trunk, there is an option for "option". You can try that. But even if there are only few calls and the amount of keep-alive might look ludicrous it makes sense to use the registration model. If you compare with how much traffic is being generated by watching a video, the keep-alive again looks more like a rounding error again. Actually depending on the firewall setup or if there is no firewall, you might be good with refreshing the connection every 5 minutes or so, which would really keep the overall overhead small.

It's really just an internal way of storing the data. I would not dig too deep into this, this is just a hack to try what happens when you set the password from the outside.

The PBX generally pools connections, which is for example also necessary for Teams. Usually there is some keep-alive traffic, so that the one TLS connection stays up for days, weeks and hopefully many months and then there is only one TLS handshake in the beginning. This is also the only way to keep TLS working behind NAT. 5 minutes sound to me like the connection idles and then gets torn down. If there is no REGISTER, what would still be an option would be — OPTION. This would generate keep alive traffic if there is no REGISTER in use.

We keep getting tickets because servers are running out of their license. This is a problem that can be avoided by having your favorite uptime checker looking at the PBX from time to time and report when it has problems fetching the license. We had it already for SNMP, but it's also available through the REST API. We have also lined this up for version 68.0.30, and the link is here. BTW it also makes sense to check if certain certificate expire, which has become another frequent and avoidable problem with running the problem. For those you don't need anything from the REST API because most scanners are able to parse the license from the HTTPS connection.

Totally agree. We are addressing this in the 69 build in a more general way, and this should be available soon. In version 68, you need to navigate to the settings, then on the right right there is preferences where you can select the ringer device.

I just tried on a snom phone — it worked as expected. Maybe the problem is that the display is supposed to show a @ sign (like 38 Joe Doe (@35)) and the device is not able to handle the character?

The users directory contains the references to the extensions. Then in the user_alias you will find the references to the users table, because users can have multiple alias names and they can all have their properties. Its good old relational database design...

You can actually write the private key, use the "TLS key log file" in the security settings for this. Wireshark is able to read this.

Seems there was a glitch in the web interface, we'll fix it in the next build.

69 is using passkey, which puts the burden of the second, third, ... factor on the browser and operating system. It's essentially the job of the operating system or environment to make sure that the user is the user. Passkeys are available on all mainstream browsers today and it is heavily promoted by the FIDO alliance, though admittedly users need to get used to the concept more. But it will happen.

It should make no difference what phone model is being used as long as the check-sync works with that phone model. At least a complete reprovisioning after a reboot should update the label.

Do you mean the template anvil-sysconf.xml? {elif model == "X5U" || model == "X5S"} {if bgimage:picture:fanvil4 == ""} <AutoEtcUrl>{get app_bgimages}/fanvil4.bmp</AutoEtcUrl> {else} <AutoEtcUrl>{https-url}/{get bgimage:picture:fanvil4}/logo-fanvil4.bmp</AutoEtcUrl> {fi} If there are models missing, you could just add or just change them there?

There are servers that have more than 30K extensions on it, however with a low usage in terms of actually having a registration and or making a call. It does not matter how those extensions are subdivided into tenants. As for active registrations, 2000 should be a good number and as for active calls, depending if they perform call recording, SRTP and transcoding, 200 should be rule of thumb. Of course it depends a lot on the CPU, but those numbers are for a reasonable modern CPU with two cores. Having multiple servers helps to not put all eggs into one basket but still maintain some efficiency with running. For example, if you have 100 tenants on one server, you need to perform only one software update instead of on hundred and you need to pay for only one VM instead one hundred. If you would double the number of tenants on it, the scale effect would improve only from 99 % to 99.5 % so that is why it does not make sense to totally overload a VM.

IMHO something that should be really simple for Grandstream to address.

The name localhost is a special "DNS address" in the parameters for a tenant. It goes back to the old times when PBX were running on a random IP address without the luxury of having a DNS address assigned to them. It just matches anything. It is not related to the IP routing. Well if there is one file missing that math would still work. But extensions can also be disabled or just have no license. Passwords need to be encrypted, otherwise there is no way to have the system e.g. compliant for healthcare. Passwords that humans enter are sensitive information and should not be visible anywhere, not and especially not to the administrator. If 3CX sends them in CSV files, they might be in trouble regarding compliance and actually general security. But you can export the list of extensions, just click on "Export as CSV" in the accounts overview.

The wallboard API is pretty old — we did not take anything out but I would not build anything new on it. In the next few months we have a focus from "work from home" to "accountability in working from anywhere", which obviously requires more reporting.

As for emergency calls, it's just smart to make sure that you can call the emergency number. In some countries it might be the law, and in others it just makes sense. I agree a hotdesk phone is not the right choice for a lobby phone. The next version will actually make the login possible and then let's see if there is anything else useful that can be associated with that account type.

If there is a phone in the office you would want to be able to place a call to an emergency number. For that functionality you need to be registered to the PBX and you can't just recycle the extension number of a regular user. Let's say you have a shared office with 100 desks, and 200 people working for the company, many of them working from home. Then it makes sense to pay the regular extension price for those and a small amount for the hot desk accounts. If there is additional functionality for a hot desk account, we can think about adding that as well. This would be about someone randomly walking to an empty desk and want to something. Maybe calling the front desk? That would be something that could make sense. Internal calls would be debatable, especially if this is in a public area or lobby and you don't want strangers to call employees up or even start overhead paging.

Hmm looks like that account type did not even allow *70 we'll have to fix this in the next build.

The hot-desking accounts solve the problem that in a co-working space you otherwise would have to pay almost twice — one time for the physical phone on a desk and another time for the user. The desktop phones need a dummy-extension, so that the phones can be provisioned and can dial log-in, log-out and emergency calls, but not much more. That is why they are prices far below other extensions.

You can enable PCAP on trunk level as well. However it tracks only traffic for calls, registration traffic is not being recorded. But what you can do is to filter the SIP packets by IP address, then you get a good picture on that is going back and forth with the trunk.

We did check. There was no colon behind the header name, also not in the Message-ID and it was consistent. Anyhow, it is not a big deal and we'll just have a space everywhere and also a Message-ID in 68. It should appear in a few days with the next build.

It is in /reg_texts.htm in the web interface.

Absolutely. Failover when the datacenter is under attack and goes down is one thing. But when an administrator accidentally makes a stupid move is another. I would say the latter happens more often. Then having a snapshot not too long ago can be a true blessing. And it's really easy and cheap in most data centers, including EC2.