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. _______________________________________________ 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/
