You think it’s hard work keeping your Metaswitch software up to date? Just wait until you have thousands of IP phone handsets from multiple manufacturers deployed throughout your customer base – each a powerful computer running a specific version of firmware and with its own configuration settings.
Now imagine you forgot to enable daylight savings on the phones, and so every single user is complaining that the time is wrong. Or imagine that there’s a bug in the firmware for all phones of a certain model – so you need to do a firmware upgrade.
How is this even possible?
This is part one of a two part article looking at how a service provider can manage and maintain the configuration for all the SIP phones they have deployed in their network.
In this introduction we’ll set the stage, and then in part two we will dig deeper into Metaswitch’s SIP Provisioning Server, to see how that product helps to solve this problem.
Where does phone configuration come from?
So looking at the big picture, there are four general approaches for configuring a SIP phone:
- Use the settings menu on the phone itself to configure every single setting (including DN, password, SIP registrar, dial plan, features, etc). Pretty painful.
- Once the phone has an IP address, access a web-based admin screen on the phone itself, and configure those same settings through the web interface. Much easier, but it doesn’t scale well.
- Have some kind of central configuration file on a provisioning server somewhere, then use approach #1 or #2 to tell the phone the URL of this server. The phone then connects to that server over HTTP/HTTPS and pulls down its configuration.
- If the manufacturer supports something called Zero Touch Provisioning (ZTP) the phone will automatically reach out a redirect server run by the phone manufacturer. This redirect server looks at the phone’s MAC address, and then tells the phone the URL for the provisioning server managed by the service provider who owns the phone. The phone then pulls it’s config from that server as in Option 3.
The first two approaches aren’t bad if you’re only configuring a single phone, but for anything more than that they are incredibly time-consuming and cumbersome. For our purposes they should be limited to lab environments.
Options 3 and 4 are both much more effective ways to manage a large-scale deployment – the only difference being during the initial provisioning of the phone.
- Option 3 works fine if your installation/provisioning team are involved in the phone configuration – either by testing the phones in your lab before shipping to the customer, or else if one of your technicians is on-site to set up the phone system at the customer premise.
- The value of ZTP really soars if you’re selling to remote customers at scale – to the point where you can drop ship phones directly to the customer without ever needing to be directly involved. There are certainly some advantages to this, but as we’ve discussed elsewhere one of the key advantages you have as a local service provider is that you can put boots on the ground to help get things running for a new customer – so there’s potential to over-optimize here. ZTP is certainly helpful in all scenarios, but I wouldn’t stress about it too much unless you’re operating at high volumes.
In part two of this article we’ll dig into the Metaswitch SIP Provisioning Server – so you can see what the UI looks like, understand the security model, and we’ll walk through some examples so you can see how everything fits together.
