Vodia PBX

Ok I think we found the problem. There was a problem with the minifying of the JavaScript code, [ [ bla bla ] ] made [[bla bla]] out of it which is a translation item, which does not exist though does not get displayed. Please try to drop the attached file into the pbxwebui/js directory (create it) and see if that solves the problem. usr_portal.js

In the latest version it seems to work for me. Does it really only depend on the PBX version? There were also a couple of changes in the browser regarding what code can be executed, and the pie charts are not coming from the PBX itself (www.google.com).

We don't have a firm release date yet. The problem is that the whole flow works different in V2, and billing has to actually triggered from the web interface and cannot automatically run in the background (as far as we can see now).

ACK. The API call for creating the account had only a limited set of settings that can be written initially. We will add another API call of there are other parameters that need to be set. Should be in the next builds from 59.1 on.

When you log in to the Yealink RPS web page you should see what the PBX has done (if it has done anything).

Can you attach an example here what you put into the textarea?

Oh please don't use such an old version, it does not support SHA-2 hashes for modern certificates yet (see e.g. https://security.googleblog.com/2016/11/sha-1-certificates-in-chrome.html). This is why that version cannot communicate with the license server. Please just use version 59.0 or if you want to use the old web interface, version 57.0. The Win64 build for 59 is currently not available, please install version 58.0 and then upgrade to http://vodia.com/downloads/pbx/version-58.4.xml through the web interface software upgrade. Win64 for 59.0 will be available Thursday.

59.1 is not there yet. 59.0 is the latest.

No you don't. This is just some left over work of having the new web interface.

Well those settings caused the phones to lead every single frame from the PBX web server actually through multiple HTTP requests, which is a kind of DoS to the PBX web server. Today, there is H.264 or at least MJPEG to handle this job much better.

There are two problems here... The first problem is that the REST API needs to do a better permission check for those settings. The second problem is that the front end needs to hide those settings, so that the domain admin does not even get tempted to change them. We also need to better address multi tenant deployments where the domain admins should not even see e.g. trunks or dial plans. This will require some changes underneath.

The provisioning password is today the MAC address password. You can also provision a phone with the web "master" password, but that is not suggested and that is not in the latest templates. IMHO that is the right way to do this. In the next version we will generate a special LDAP password; then a VoIP phone should never have to use the web password or the SIP password. Having the LDAP password separate solves the problem that many VoIP phones don't support TLS for LDAP which makes this password specifically exposed.

The provisioning password would be the "key" to the SIP password and the LDAP password (and the PIN). Why not putting them together into a client/device password? At the end of the day, the device needs only one password, there is no further user interaction anyway.

The LDAP password is on our list... SIP password should be in a good space because we practically have a separate SIP password for each provisioned device. The web password is practically "the" account password now, and the PIN the IVR password.

I would fall back to good old simple patterns: Pattern: 800xxxxxxx|855xxxxxxx|866xxxxxxx|877xxxxxxx|888xxxxxxx Replacement: * If that does not work you can as well split it up to multiple lines.

Oh I was under the impression we were dealing with inbound (trunk settings). For "complex" patterns in the dial plan, you need to look at user@domain. So the pattern would be 1?(8(00|55|66|77|88)[2-9][0-9]{6})@.*

Hopefully I did not get lost in the brackets, but that looks about right...

We have built version 59.0 for all platforms (Windows 32/64, CentOS32/64, Debian32/64, mini 1/2/3/4, Apple MacOS and FreeBSD64). The release notes are to be found at https://vodia.com/doc/releasenotes590 as usual. The main topic for this release was to mature the new web interface. This includes form validation, but there were also problems with entering information and retrieving lists. There are also some new goodies like the ability to log TLS keys for Wireshark analysis and TrueCNAM support. We also have Deutsche Telekom trunking working in this release, which should be important to help with the ISDN transition in Germany. And we have added support for the new Cisco phones which can be seen as a major milestone on our interop list and help with the customers on boarding process. The build also contains a few improvements under the hood which should improve the performance of the PBX, especially when there are lots of calls in the history. In the next release we plan to work on a faster startup procedure, the Freshbooks V2 API, a rework of the emails and a unified buttons interface for all phone models. We decided to release 59 without those changes to speed up the release process and have a pretty stable version based on the new web interface.

If you copy the pbxwebai (that stands for PBX Webpages Administrator Interface), pbxwebui (that stands for PBX Webpages User Interface) and the webpages directory (which contains changes that were made from within the web interface) it would clone those changes to another server. If there was anything in the webpages directory you will need to restart the service so that the PBX can read those pages in. The other two directories do not require a restart.

Yea we did not build that version but 58.5 should be available for mini3.

Try replacing \d with [0-9]

Binding a domain to a specific IP would only work if all other domains bind to a specific (potentially another) IP as well. You could as well just run two instances of the PBX and bind each instance to the specific IP: But IMHO that is overly complicated. Every device should today support Server Name Indication as every device should support AES and actually TLS 1.2.

Why did that work work?! It should work... There are also ring tones that should be downloaded into the phone over HTTPS. IMHO not big secrets, but generally it is a good idea to encrypt everything.

You cannot trust an endpoint. If you give one endpoint the credentials to pull all configurations for a domain, you can as well just give all endpoints the same username and password...

We have made some changes for the new Cisco phones that will be part of 59.0; however it is clear that we need to rework a couple of modes in the buttons area. But we will do that after 59.0.