-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Paul Mossman Sent: Thursday, September 10, 2009 9:35 AM To: Scott Lawrence; [email protected] Subject: Re: [sipX-dev] Automated phone provisioning - XX-6490
Scott wrote: ... > > >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. > > How do you think you can get its MAC address? Don't assume > that the phone is on the same subnet - it might not be, and > if not then the only MAC address that will be in the arp > cache is that of the next-hop router. An auto-provisioning > feature is most useful specifically in larger enterprises > where multiple subnets are more likely. I'm pretty sure I can do it with Polycoms. The XX-6490 prototype will prove it. > > 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. > > Better yet - configure the phone so that's all it can do - > taking it off-hook auto-dials the provisioning IVR. Others have requested local and emergency dialing capabilities. Either option is possible. > > 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? > > I think that un-provisioning should be left out of this - the > potential for abuse is pretty high. Bear in mind that you would need credentials to un-provision. A user's credentials could only un-assign that user from the phone. The phone would only become un-provisioned if Lines were removed. I guess then only superadmin credentials could un-assign an External Line. > It is probably also worth considering whether or not > auto-provisioning also depends on the user account being in > an 'auto-provisioning enabled' > state, and whether that state should be automatically changed > once a phone has been provisioned, perhaps by having the > provisioning authentication code for a user be usable only > once (I start my new job - HR tells me where my office is and > what my code is, I go to my office, pick up the phone, it > dials the IVR which prompts me for the code, I enter the code > and the phone hangs up reboots and comes up as my phone). I like the idea of an 'allow auto-provision' boolean. But in order to keep things simple, let's use the User ID and PIN as the code. We could certainly have another boolean that permits one auto-provisioning attempt, but then gets switched off. Might as well also have an 'allow un-provision' boolean too. Probably these settings would not be in Phase 1. > I suspect that there are at least two desirable states: Sounds a little too complex. > Incidentally - it should be possible to call one of > these phones > from the admin display and/or send it a message that either > activates the MWI indicator or puts a message on the phone > display. This allows an admin to say "go to the next room and > take the phone that is ringing" (or has a red light, or > whatever) - anyone who's run a network with a lot of identical > devices in it has faced the problem that they can find the > network location of the device but don't know where (or which > one) it is physically. Sounds like a nice idea. But, to do that the admin would need identify the phone (by MAC) in the GUI. If he goes that far, then it would be a lot easier to just provision the phone right there. One vendor with an Asterisk implementation uses a feature where a new Polycom is plugged in, and is provisioned into a group of new phones. The phones received a registration and a unique number for its assignment. As an example - a16. The administrator can then build the user profile, and assign the phone a16 to that user, and the phone reboots. It's very simple, straightforward, and easy for an administrator. I like the idea of the IVR. However, remember that not all end users are technical, or understand any of this. And, most, unless they are into technology like those on this list, really just want to sit down at their desk, pick up the handset and dial. Much of what is discussed here has a very high coolness factor, but is not something that the end user will give a rip about. They just want their phone to work when they sit down. With regards to hotelling, that has been intertwined in this discussion, it might be worthwhile to look at setting the hotelling features to a calendar. As an example, in Outlook, if someone schedules a resource (in this case a room), auto-provisioning could happen based on the time of day for that extension based on the calendar. With that, you are using a resource that is already able to interact with sipXecs, and use that resource to assign and un-assign telephone resources to the room that is scheduled by the end user. Using the GUI, a calendar could be created that has a range of extensions for hoteling, and a user can simply schedule the resource through that calendar, which provisions the phone. If the same scenario is used for unused hotel desks, the un-provisioned hotel phone would have a16 on it. The user could simply schedule themselves for a16, or the desk number. _______________________________________________ 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/
