On Wed, 2009-09-09 at 22:29 -0400, Paul Mossman wrote:
> 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.
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.
> 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.
Better yet - configure the phone so that's all it can do - taking it
off-hook auto-dials the provisioning IVR.
> 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.
That's also an interesting feature, but is in some ways orthogonal. I'd
consider it separately.
> Both of these options are compatible, and can be done/undone using
> either method. This would facilitate hot-desking.
Let's be careful - hot-desking (aka hoteling or drop-in phones) has a
bunch of other issues, most notably the expiration or explict
un-configuring of a phone when the temporary user is done with it.
> 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. Similarly, it should not be possible for a
user to provision an arbitrary phone in this way - only a phone that has
no other provisioning.
Damian commented:
> 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 applies also to phones that are 'discovered' by a user calling into
a provisioning IVR.
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).
> - 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.
I suspect that there are at least two desirable states:
* Phone has only a dummy but unique identity in an 'available'
group; this identity has no permissions. As such, it can
typically make at most internal or emergency calls. Because
they are in a group, it's easy for an admin to find these and
treat them as a pool from which phones can be assigned. An
operation on a normally configured phone would move it into this
'available' group and reconfigure it.
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.
* Phone has been set up to be 'hot-configurable'; the only call it
can make is to the configuration IVR (which might need to have
an option for transfer to an emergency call).
_______________________________________________
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/
