The goal of this project were twofold: • To completely eliminate the need for me to touch the phone to provision it. I want to be able to create a profile for it in the database, then simply plug the phone in and let it do the rest. • To eliminate per-phone physical configuration files stored on the server.

The configuration files should be generated on the fly when the phone requests them. So the flow of what happens is this: • I create a profile for the phone in the database, then plug the phone in. • Phone boots initially, receives server from DHCP option 66. Script on the server hands out the correct provisioning path for that model of phone. Reboots with new provisioning information. Wasatch Serial Keygen more.

• Phone boots with new provisioning information, begins downloading update SIP application and BootROM. • Phone boots again, connects to Asterisk. At this rate, provisioning a phone for a new employee is simply me entering the new extension and MAC address into an admin screen, and giving them the phone. It's pretty neat.

* Note: *there are some areas where this is intentionally vague, as I've tried to avoid revealing too much about our private corporate administrative structure. If something here doesn't make sense or you're curious, post a comment. I'll answer as best I can. Creating the initial configs I used the standard download of firmware and configs from Polycom to seed a base directory. This directory, on my server, is /www/asterisk/prov/polycom_ipXXX, where XXX in the phone model. Right now we deploy the IP-330, IP-331 and IP-4000. While right now the IP-330 and IP-331 can use the same firmware and configs, since the IP-330 has been discontinued they will probably diverge sometime in the not too near future.

With the base configs in place, this is where mod_rewrite comes into play. I added the following rewrite rules to the Apache configs. 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. In practice this all works very well, and cut the time it used to take me to configure a phone from 5-10 minutes to about 30 seconds.

The configuration files should be generated on the fly when the phone requests them. To understand what these do, you will need to take apart the anatomy of a Polycom boot request. So, for now, we generate those dynamically as well when the phone requests any of its *-directory. Download Game Gratis Untuk Hp Nokia 5800 Xpressmusic. xml files.

Basically, as long as it takes me to get the phone off the shelf and punch the MAC address into the admin GUI I wrote. I don't even need to take it out of the box!