-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Mossman Sent: Monday, September 14, 2009 12:45 PM To: [email protected] Subject: [sipX-dev] Design approach for XX-6490: Polycom auto-provision
Hi all, We pretty much have consensus on how this feature will look. So below is my design approach. I'll describe is as flow through the auto-provisioning of a Polycom phone. 1. An un-provisioned Polycom boots on the network. It first makes an FTP request for a [MAC].cfg file, which fails since this phone is not provisioned. 2. Because the latter fails, the Polycom goes on to request 000000000000.cfg, which is controlled by the auto-provisioning feature. This file tells the Polycom where to pick up the rest of its configuration files. The registration configuration file will be specified as an HTTP URL. The auto-provisioning feature will service this URL dynamically in order to generate the unique ID for the phone. (The ID will simply be randomized, so uniqueness is not 100% guaranteed.) The configuration will specify a single registration: - credentials: a new "~~id~autoprovision" special user, with SIP password. - label: the unique ID to be displayed on the phone. - display name: "[unique ID]-[MAC]" (From: header user-part) I'm thinking that this URL will be handled from Apache by a CGI. Note that the URL will contain the phone MAC address, so the Apache config will need to accept a wildcard in the CGI path. The "~~id~autoprovision" special user's SIP password is stored in the DB, which is owned by sipXconfig. So I think sipXconfig will need to generate a "sipxautoprovision-config" file containing this password. (I hope there's an easy way to do this without a corresponding service...) 3. The Polycom will perform a successful registration. 4. This will trigger the takeAction() method of a new SipAutoprovisioning register plug-in, which will examine the REGISTER message. If it's from a Polycom and for "~~id~autoprovision", then the following information will be extracted: - the IP address from the Contact: header - the unique ID and MAC from the From: header - the model from the User-Agent: header This information will then be enqueued so that it is handled by a new sipXregistry auto-provisioning thread. 5. The new sipXregistry auto-provisioning thread will wake whenever there is an entry to be dequeued. For each entry it will use the sipXconfig REST API to create a new Polycom Device->Phone. The unique ID and IP address will be put into the "Description" property. 6. At this point the Polycom has been auto-provisioned, and ready to be assigned a user. The superadmin can correspond a physical Polycom with a sipXconfig entry by searching for the unique ID. The IP address in the Description may also be useful. Hopefully Phase 1 can also include a new "-unassigned-" filter, which would match phones with exactly zero lines assigned. (Note that this would match all unassigned phones, not just those that have been recently auto-provisioned.) Comments, questions, suggestions? Thanks. -Paul [email protected] +1 Sounds awesome from a user perspective! _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
