Hi all, XX-6490 is only a Polycom-specific prototype, but I've been asked to start a discussion on the user experience of the end feature.
Below is a consolidation of some thoughts that have been circulating. The main goal is to be able to provision a phone without manually entering its MAC address in sipXconfig. Consider a new phone that has just been taken out of the box. It has no configuration, and sipXconfig is not aware of its MAC address. When connected to the network, the phone used DHCP Option 66 to learn the address of the sipXconfig phone profile server. (Or it could be manually programmed with the address, if DHCP Option 66 is not available.) >From there the phone should be able to acquire configuration for registering to some "provisioning" AOR. sipXecs should then be able to learn of the phone, including its MAC address. Options for provisioning this phone: 1. The phone's registration would allow it to dial an IVR that assists provisioning. i.e. The user or admin calls into the IVR, keys in the (numeric) User ID and credentials, and the phone is automatically assigned to that user. A profile is generated and upon hanging up the phone reboots. The IVR should also be able to un-provision a phone. 2. sipXecs has learned of the phone. So, the phone shows up in sipXconfig, as part of some collection of phones that are available for provisioning. The admin creates an assignment between an un-provisioned phone and a user. A profile is generated, and because the phone is registered it reboot. Both of these options are compatible, and can be done/undone using either method. This would facilitate hot-desking. Questions: - Should a User be able to provision and/or un-provision a phone? Or should one or both of these be restricted to admins? - Should un-provisioned phones automatically show up under Devices->Phones, with new filter option? Probably, otherwise we'd have two separate states of phone un-provisioned-ness. Though you would then expect certain phone settings to remain when a phone is un-provisioned, which could be undesirable. Thoughts? -Paul [email protected] _______________________________________________ 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/
