The last couple of days was a journey into Polycom's way of provisioning phones. We do provision Polycom phones for many years already; however it was time to dust the template off a little bit and make sure that the provisioning process gets easier and also more secure.
We used to provision the phones over HTTP (or TFTP), which is obviously not very secure. That needed to be changed to HTTPS. This was the first challenge. After a factory reset, HTTP provisioning will usually not work because the phone will reject the PBX certificate. That is why the provisioning has to first use HTTP, set up the TLS parameters and then re-provision the phone over the HTTPS connection, where the PBX can now include the passwords and other sensitive information that should not be visible to the network.
The problem is that when provisioning phones in the LAN, there is usually no useful certificate available. So we need to tell the device that it should not check the certificate. And the way the Polycoms work, we also need to provision the Root CA into the phone that was used to sign the certificate on the phone.
For the build-in certificate that means we need to send the Vodia Root CA to the phone. For other certificates, this will be end of the certificate chain. It is important that the Root CA is part of the chain, because the PBX has no other way of knowing the Root CA (and it usually does not hurt to include that Root CA in the certificate chain).
So we have added two more settings:
 

• Try to provision phones securely: If this is set the PBX will try to use HTTPS for provisioning. Right now this setting has only effect only for Polycom phones; but future versions will likely do that also for other phone models that are capable of secure provisioning and ultimately SIP over TLS.
• Have phones validate the certificate: When that setting is on, the PBX is supposed to have a certificate that matches the domain name. This setting makes sense when you have "Use domain name instead of IP address" turned on and either a wildcard certificate on the PBX or a certificate for each domain. 

I also had to find out that the phones don't send the server name identification if the address is a private IP address. That means multi-tenant PBX operation in a LAN requires that you use DNS names. Anyway this should be a rare case.
While we were on it, we also added secure LDAP to the Polycoms. Now that the Polycom phone can use SIP TLS, why not LDAP over TLS. It makes a lot of sense because the authentication for LDAP is using more-or-less clear text passwords which really should not sent over TCP.
The new Polycom templates also take care about the background image provisioning, so that you can easily drop a SVG image into the domain which will then show up on every phone (I used the Tesla logo, hope that is okay).

The new templates are using an improved syntax for controlling the rendering of content. Because we needed to make rendering depending on various flags, we have added a new syntax that allows "and" and "or" operators and comparision operators. So for example {if https == "true" || validate_cert == "false} will not check the condition inside and then suspend rendering depending on the condition. And we added nesting of the various "if" commands, so that parts can be rendered depending on more complex settings. This was very useful for the new Polycom templates.
And the new templates use our new button profile, where the PBX already shows what buttons are available for that phone model and you just need to select what you want to have in the buttons.

The next build 59.4 will have all that included.