It's worth noting that, if you don't pass it in the form of a fully-qualified URL, it will default to TFTP.
But you can pass any format you can add to the phone.
When the phone receives the server from option 66 and requests 000000000000from the root directory, we instead forward it on to our file, which handles the initial configuration.
Our script looks at the HTTPThese files all contain a variation of my previous auto-provisioning configuration config, which tells it the proper directory to look in for phone-specific configuration.
You may want to have some kind of cleaning script to remove log entries over X days old.
Passing the initial config via DHCPAt this point, we have a working magic configuration.
But having the phone fill up a directory full of logs is ungainly.
Phones, once configured, fetch dynamically-generated configuration files that are guaranteed to be as up-to-date as possible. except that it still requires me to touch the phone. By default, Polycom phones out of the box look for a provisioning server on DHCP option 66.
Their directories are generated out of the same database, and log files are added back to the same database. I'm still required to punch into the keypad the provisioning directory to get it going. If they don't find this, they will proceed to boot the default profile thats ships with the phone.
A quick change to the configs makes it possible to schedule the phones to look for changes at a certain time: This causes the phones to look for new configs at 1AM each morning and do whatever they have to with them.
Conclusions The reason all this is possible is because Polycom's files are 1) easily manipulatable XML, as opposed to the binary configurations used by other manufacturers, and 2) distributed, so that you only need to actually send what you need set, and the phone can get the rest from the defaults.