Simpler is better. IVR approach by either user or admin would be very nice (but not replacing option of GUI for admin)
Basic install & provisioning by the user is desireable. One thought is to have the admin control an 'on/off' switch to allow/disallow when a user can do their own provisioning - for basic operation (ie address and default service capabilities). It is up to the admin if they leave this enabled or only when a new user event is triggered (new employee, new phone deployment). Once provisioned by user this could be identified to the admin as a 'basic provision' that would then need assignment to group, branch, additional services etc. I think it less important for a user to do their own unprovisioning. -----Original Message----- From: Campbell, Alfred (BL60:9D30) Sent: Thursday, September 10, 2009 12:33 AM To: Mossman, Paul (CAR:9D30); [email protected] Subject: Re: [sipX-dev] Automated phone provisioning - XX-6490 > 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/
