Trouble in RPS land

Christian Stredicke
CEO of Vodia Networks
Vodia PBX RPS

It must be more than 10 years that snom started a service called remote provisioning service which tells phones that just come out of the factory where to fetch their configuration data. At a time when nobody had an idea what hosted PBX is, this has become an important feature today for setting up VoIP phones without ever having to touch them. This makes it possible for providers to ship phones to customers directly from the distributors, which eliminates cost and time for everyone involved. A factory reset would somehow bring phones back into a reasonable state, making support a lot easier than trying to tell customers to navigate through menus and guessing passwords.
Other vendors soon followed suite. The original protocol from snom was adopted and sometimes improved by other vendors, and the RPS became practically industry standard. The Vodia PBX, then marketed as pbxnsip or snom ONE, supported it from day one.
In version 60.1 we have started to use the new JavaScript backend to handle RPS. This gives us great flexibility, including the possibility to not only change a URL on the fly, but also the whole API if we have to.
So far so good. However lately there were changes made to the RPS, that are causing trouble in RPS land. snom and Yealink have both changed their redirection URL. This is causing at least two problems:
 

  • PBX software needs to be updated to reflect the new URL. This is a big problem because many providers operate their favorite version of the PBX. Upgrades are a major project; doing this just because a URL has changes is not good for making friends.
  • Old phones and old firmware still has the old URL built in as well. Upgrading such old phones is not only a lot of work, it is often risky because new firmware has new features and other surprises that nobody wants. 


We can only guess what the reason for the change is. snom was using a certificate that was signed by a snom certificate which was a problem if you wanted to manage the redirection e.g. from a browser. This was a good reason to offer another server or even port that uses a certificate that can be verified by a browser. However instead of killing the old port snom could have simply opened a second port to the same server or service - one for the old phones and another one for new phones, web browsers and anything else. Yealink was already using a valid certificate; while new features or a web front end are always welcome, it would usually not require to change the URL.
Another reason why changes became necessary would be that the phone vendors want to use client authentication using client certificates over TLS. Because the newer phone models have their own client X.509 certificate built-in this is a great way to make sure that the device requesting a redirection tells the server who is actually is requesting the redirection. However again this would not require any changes on the web or API side. All it would require would be opening another port that requests the certificate. For example, open port 6789 for all models produced in 2018 and port 6790 for all models produced in 2019. This would be totally invisible for the administrator, except that the respective port might need to be opened on a corporate firewall.
It is now hard for us at Vodia to recommend that to do. Supporting both URL depending on what MAC address is used will be a whack-a-mole, a support nightmare. Staying with the old URL is also not an option. In a nutshell it means that whatever was provisioned with the old URL hopefully never has to be factory reset. For new phones that are deployed, the PBX and the phones use the new URL. Whatever does not fit into this will require manual work.
We are still in the beginning of hosted PBX and RPS. Seeing it from that perspective, a change to doing this properly is a good idea.

P.S. If you are still using the old URL provisioning.snom.com you need to make sure that you still trust the old certificate used for the old RPS (in order to do this import it as trusted server Root CA in the PBX web interface for the certificates):

-----BEGIN CERTIFICATE-----
MIIDOjCCAqOgAwIBAgIJALY0/+gO/+3nMA0GCSqGSIb3DQEBBAUAMHIxCzAJBgNV
BAYTAkRFMQ8wDQYDVQQIEwZCZXJsaW4xDzANBgNVBAcTBkJlcmxpbjEeMBwGA1UE
AxMVcHJvdmlzaW9uaW5nLnNub20uY29tMSEwHwYJKoZIhvcNAQkBFhJ3ZWJtYXN0
ZXJAc25vbS5jb20wHhcNMDkwNDI5MTYwNTUxWhcNMzMxMjE5MTYwNTUxWjByMQsw
CQYDVQQGEwJERTEPMA0GA1UECBMGQmVybGluMQ8wDQYDVQQHEwZCZXJsaW4xHjAc
BgNVBAMTFXByb3Zpc2lvbmluZy5zbm9tLmNvbTEhMB8GCSqGSIb3DQEJARYSd2Vi
bWFzdGVyQHNub20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC/qckJ
DEtpAO5DKRiVjRb5fHLq4DRH9/Xqi+vAN/cmtZfk1lUwQECK9WefcGyEkWOnUomB
IfHgIodkZaq3chhPGWZKFK31Z/fPOQAjEsfhsY7jaWlW5hQ7Pi8qW8aLpqpoy4dZ
hHx5HpYl0xoJ8Q4+A28IqpB5sjjRSxqoNyUxxwIDAQABo4HXMIHUMB0GA1UdDgQW
BBQzwLdiIa/m2f8T6hrnG91TSmZZeTCBpAYDVR0jBIGcMIGZgBQzwLdiIa/m2f8T
6hrnG91TSmZZeaF2pHQwcjELMAkGA1UEBhMCREUxDzANBgNVBAgTBkJlcmxpbjEP
MA0GA1UEBxMGQmVybGluMR4wHAYDVQQDExVwcm92aXNpb25pbmcuc25vbS5jb20x
ITAfBgkqhkiG9w0BCQEWEndlYm1hc3RlckBzbm9tLmNvbYIJALY0/+gO/+3nMAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAsRyzDBXMcURRgATFPKNMDMDA
1uHOc4UvepZFCU/pH7Y3N9zJ/5jMvcGIinVXNIG+VujPjwmZC0keKz7MIP/G2bKr
I4ByUvBKKTkgCW3R3oZ4TKh/nNYwGbJqL/OGE3eYvOr01rHDacqx6ronI30jXrNz
Dh4zETFy1cPNsVr6co8=
-----END CERTIFICATE-----