2600Hz Blog

Read about cutting edge telephony thought leadership, 2600Hz product updates, customer use cases and more!

Featured Posts

Subscribe to Email Updates

Why Provisioning Sucks

Screen Shot 2018-11-05 at 4.10.57 PM

(And here’s what 2600Hz is doing about it)

If you have ever dealt with phones, chances are you hate provisioning. If you do it manually, it is exceedingly tedious. If you do it automatically, it can be disastrous. Many organizations opt for a homogeneous equipment mix, supporting only one manufacturer with a proprietary provisioning solution because it works and that’s good enough.

Here at 2600Hz, almost all of our clients run heterogeneous infrastructures, which means we have to handle many different manufacturers so we couldn’t use the proprietary solution. In addition, we work with a lot of handsets and we realized pretty early on that manual provisioning wouldn’t work for us. 

Why is this hard?

It’s actually not that hard to provision a single phone, or even 100 phones. Heck, it’s not that hard to provision 1,000 phones if they’re at the same site and made by the same manufacturer. See, routers have this awesome option called DHCP Option66 which lets you point phones en masse towards a provisioning server. All of the devices that connect to the router will receive a URL in a packet header that points the phone towards the config files. This is how the process works, but it’s worth diving into how this works over the Wide Area Network (WAN) in a little more detail. Let’s lay out the process for setting up a handset over a WAN:

  1. Brand new phone arrives from factory
  2. Phone has provisioning URL added to the on-device GUI - this is DHCP66
  3. Provisioning server creates a provisioning profile for the handset containing all of the configuration files (MAC Address used for identification)
  4. The phone is attached to the corporate network and attempts to connect to the provisioning URL in the GUI
  5. The provisioning server recognizes the MAC ID of the handset and sends the corresponding configuration files after authenticating the phone
  6. The phone receives the firmware and, if this is a secure environment, performs a checksum on the configuration files to make sure they match
  7. If everything is matching, the phone will begin the update process. Once complete it will enter service.
  8. Every few minutes (or days) or when the phone powers on, it will repeat this process starting at step 4

This process has to work every time for every handset. Now, you might think that after 150 years of telecom, there might be some standardization between vendors. However, that’s certainly not the case with respect to provisioning. Every manufacturer has a different way of crafting their provisioning files, from the number required to boot up a phone to the names of the files. Now there’s even more added complexity with companies acquiring each other, like Polycom’s acquisition of Obihai. In this instance, Polycom rebrands Obihai devices under the Polycom name, but the config files remain in the Obihai template rather than changing to use the Polycom template. It’s enough to drive a developer batty, but this is what we have to work with. Seriously, go look at the Polycom firmware grid - it’s like a forest of incompatible firmwares!

 The Polycom Nightmare Grid

ezgif.com-crop

https://downloads.polycom.com/voice/voip/uc_sw_releases_matrix.html
If you want to present your users with simple-to-consume services, you must first conceal complexity. That’s a recurring theme in all the work we do at 2600Hz, but it’s perhaps no more true than what we’re doing with respect to provisioning.

What are we doing about it?

At 2600Hz, we believe in presenting simple interfaces for complex services. When we think of provisioning, we want our clients to experience a service that “just works”. We don’t allow folks to see firmware file names because we know what works with our servers. Power users can get this functionality back with trivial difficulty, but for the majority of use cases, the default settings are perfect. Here’s what our provisioning interface looks like in our GUI:

Picture2

 

You’ll notice that we request a user to select the brand and model of their phone, a name, and a MAC address. The only piece of specialized information is the MAC address; everything else is immediately obvious to the user. But provisioning the handset doesn’t govern how the handset might interact with the network. That’s why we’ve included some extra features to take the experience just a bit further, such as segregating combo keys and device restrictions from the main UI, while still giving you access to them in Advanced Settings and Advanced Provisioner application. With Advanced Provisioner, users can now go even deeper in the functionality of their devices in a cleaner and more intuitive UI. Available for specific brands, including Polycom and Yealink, you can take customization a step further than the UI offers. For example, you can create templates for combo keys to be disseminated to multiple devices at once to save time and effort, and eliminate unnecessary troubleshooting. 

 

Picture1

Here you can see the Combo Keys section in Advanced Settings. Our main application, SmartPBX, keeps the complexities of setting up an office to a minimum by exposing the essential business features and separating advanced functionality into individual applications.

 In summary

2600Hz has built an awesome suite of provisioning tools for our clients to help them manage their systems. Provisioning is hard because hardware manufacturers make it hard, but that’s why there was an opportunity for us to innovate in the first place. By concealing complexity from our clients, we make everything run smoother and in a much more controllable fashion. To learn more about 2600Hz and how we can help simplify your life and business reach out to us with an email to sales@2600Hz.com.

Tagged: unified communications, telecommunications, telecom blogs, uc, UCaaS, business, voip, provisioning, provisioner, VoIP Provisioner, Telecom Blog