Perhaps a separate range of "lines" can be allocated to a "provisioning group". With this range of lines, a very limited feature set (911 and calling only the provisioning AA). When a new phone is detected could it assign the first available "provisioning line" which will then allow for an IVR experience to assign a real user the the line, and also allow just that phone to reboot (using the temporary provisioning line assigned to only that phone) and start with its unique profile and normal line. At the same time, if the provisioning AA function can reverse the step (I am user 201, I no longer wish to use this phone, please de-register me), it can essentially perfrom a basic hotelling feature. I think a lot of this pieces in XX-6490 go a long way to possibly fulfilling XX-4987 in a basic way.
>>> "Alfred Campbell" <[email protected]> 09/10/09 12:34 AM >>> > 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. > I really like the whole idea as it further simplifies the install. The dial of the IVR could be a hotline so once the user/admin picks up the phone they get the Prompt. > > 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? > This should be allowed only if an admin has allowed it. Meaning if the admin has setup the phone after it has pre-registered then the user can do the next step. I don't think it should be wide open to let users pick their own user ID and setup the user. That maybe ok in a small system but could be a nightmare in a medium/large system. > - 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. > My vote on this is Yes. They should show up if they are un-provisioned and allow an admin to provision them. This could basically replace the discover mechanism we have today with a technology that is better than the same LAN. > > Thoughts? > Question: How would we be able to reboot a single phone when they are all registered to a common account? > > > -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/ _______________________________________________ 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/ </[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/
