Paul Mossman wrote: > 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. >
Something very similar to this was already discussed with relation to existing (and enhanced) discovery mechanisms. It would be a natural extension of the existing functionality to allow administrator to specify to which group all the discovered devices should be automatically added. So once the phone is discovered it can automatically inherit its configuration from the group and sipXconfig can generate configuration profile. That would require using plug-in based discovery mechanism and implementing discovery plug-on that works by analyzing DHCP server logs (that's actually one of the cheapest and most effective way of discovering new devices). As a matter of fact we already have a patch for sipXconfig that implements plug-in based discovery. > 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? Not sure what you are asking here: setting up the auto-provisioning should be left to admins. But of course it would be users who are interacting with the process - for example by using IVRs. > > - 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. Yes - once provisioned phone has to be visible just like other phones. It can be kept within a special group so that all auto-provisioned phones can be automatically found. [...] _______________________________________________ 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/
