A Technical Analysis of Plug n Dial
As someone who works with VoIP equipment a bit more closely than many people, I have seen many different provisioning schemes. I will admit, my favorite scheme to date is the one originally implemented by Sipura, which is now owned by Linksys. However, it is specific to one manufacturers set of devices, namely those made by Linksys.
Plug ‘n Dial is a scheme that is being trumpted by the fine folks at SIPphone, a.k.a. Michael Robertson and crew. I do have to give them some credit for trumpeting some manufacturer-independent standard. It’s something, I’ll grant you that, but I don’t think it is totally adequate at least from a service provider point of view.
Why does an end user care about provisioning a device? Quite honestly, they won’t or shouldn’t. Provisioning is partially for the convenience of the end user, but it is mostly for the benefit of the service provider. They don’t have to deal with end user questions about how to configure the device, they protect the credentials, protect the device subsidy (if needed) and reduces fraud. However, a poorly implemented provisioning schemes, or a good scheme implemented poorly, makes it possible for providers to “brick” the devices or have their devices “unlocked” by end users.
I have looked at the examples on the Plug n Dial site. I also have some first-hand experience with Leadtek and earlier versions of their provisioning scheme, which is obviously based on Plug n Dial. While I have to say that the 2.1 specification is definitely improved from previous versions–namely that it supports XML configs and NAT-friendly HTTP or HTTPS provisioning–it still lacks many of the security features present in Linksys devices. I am not going to get into specifics here as I fear the information may fall under an NDA. I can say that Linksys provides way more tools than simply encrypting the configuration file.
