Vodia PBX

The points was to show only the menu item that makes sense... If you are on DND, you don't want to turn it on again... and vice versa. ifn and fin need to match, and so does if and fi. The problem might be that the dnd variable might just be empty, that is why it is better to compare always to the same value, e.g. if true .. ifn true. This way it must be either the first or the second.

LDAP is actually a headache because only very few devices support TLS or at least Digest authentication. In other words, the password crosses the wire when a user presses the address book button, not good. What should we do with devices that don't use LDAP with TLS or use at least Digest authentication.

User-level address book is a topic that we need to address when revamping the user mode. Why domain import does not work on other browsers than Chrome is something that should work, we need to check that ASAP.

Would that help much? In a multi domain environment you'll probably end up with the wrong certificate most of the time. The default is the server certificate right now (you can load wildcard certificates also into domains if they match).

The PBX web interface will automatically resize the image to the needed sizes (there are more than one). When you drop an image, take a reasonably high resolution (e.g. 1024 x 768) so that the browser can down scale it (and not up scale it)

There is a setting "Automatically recharge credit for domain" in the monthly billing section that can be used for that purpose.

Usually you can use a wildcard certificate as the server certificate that will match most of the domains (e.g. *.best-pbx-ever.com) if all you clients use domain names with that kind of name.

ACK will be fixed in the next build (58.4 we are).

The SMS feature should be described in https://vodia.com/doc/admin_messages did that help? Seems like you found it... You mean the JavaScript does not allow you to save it?

Generally speaking, at least by default the PBX should never leak out passwords. However, you can (should) use the REST API for this. By default downloading passwords is disabled; there is a setting in pnp.xml called rest_show_passwords that you can change to true to make this possible. Then you can use the /rest/domain/<domain>/user_settings/<account> API call for this.

The document is from 2011. Not sure if anything has changed since then? Maybe you can try to run a wireshark to see if there is even a basic handshake going on or the port is just not open.

It is a trade off. We got criticized for leaving fields wide open, to the degree that customers don't know what would be reasonable values. Drop-downs solve that problem. In many cases there is no need for additional values. If there is a need for it you could customize that page and add the value that you are missing; however at the cost that you would miss future updates for the page. That's why it is better to come up with proposals for additional values that we happily include in the next build, so that everybody can benefit from it and that does not require you to miss out on future updates.It is a trade off. We got criticized for leaving fields wide open, to the degree that customers don't know what would be reasonable values. Drop-downs solve that problem. In many cases there is no need for additional values. If there is a need for it you could customize that page and add the value that you are missing; however at the cost that you would miss future updates for the page. That's why it is better to come up with proposals for additional values that we happily include in the next build, so that everybody can benefit from it and that does not require you to miss out on future updates.

Wir werden dann mal diese Zertifikate mit einbauen und das "DeutschandLAN SIP-Trunk Pooling" als Drop-Down einbauen. Dann sollte es einfach über Name/Password gehen und weniger als eine Minute dauern den Trunk einzurichten. Vielen Dank für die Pionierarbeit!

TimeStart, TimeConnected and TimeEnd are always in GMT.

There is a file helplinks.txt where you can set the links, also just the root for the help files.

The old snom phone models had a way to send sips Request-URI. Not sure if other devices or soft phones can do that today; but this is (IMHO) the way to tell the PBX that this call should be encrypted. The other thing that you can try is ZRTP end-to-end encryption. The PBX also supports that. But then both endpoints need to support this; for SIP trunks this will be very difficult. The VoIP security market is hard to understand. Lots of bla bla about VoIP security. We have tried a few things, even made our own firmware with ZRTP with elliptic curves for snom phone hardware; but the feedback was simple that there is no market for this at least from our perspective. The only thing that seems to sell are UDP-based SIP trunks. If you want to get all the traffic to a certain country, all you need to do is offer the lowest rates and users happily route all calls through your network, everything in plain RTP.

They obviously don't advertise TLS. Seems they use also port 5061 for UDP, which might be a little but confusing; but it is only for UDP and it is okay. I would try setting the outbound proxy to sip:sip.skype.com;transport=tls and see what happens.

You can always add additional headers, even it if just the Authorization header. We even got MMS working this way (see https://vodia.com/doc/admin_messages)

We addressed that issue in 58.3.

IMHO it should work pretty much right out of the box. The only problem I can think of would be that the certificate validation has problems, but if you add the right Root CA (if missing) then I don't see a problem.

In the old days we had actually a setting on the trunk that had the PBX assume that they are secure (e.g. PSTN gateways that are sitting just next to the PBX) and we tried to promote the end-to-end encryption. Nobody cared. Honestly I don't know if the end-to-end encryption is still enforced. Anyway the phones would have to request it by using a sips Request-URI if I remember correctly.

Ok next version will also take the old format, as long as it contains "extensions".

In the older versions we needed to differentiate between user-mode and admin mode because the same HTML code was used for both admin and user. Now that is separate and we can take that distinction out. In other words, even if you go from the domain mode into the user mode, those fields will not be visible anymore in the next version if you disable them.

Das würde passen.

What fields would you like to import? Maybe we can extend the list if this makes generally sense...