Al wrote:
> The dial of the IVR could be a hotline so once the 
> user/admin picks up the phone they get the Prompt. 

Agreed.  But there was also mention of allowing these phones to make
internal calls.  That may require a second Line registration on some
phones. 


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

I hadn't even thought of the IVR having the ability to create User
accounts...  That would be great, and agreed that superadmin credentials
would be required.

But user credentials are all that's required to provision and
un-provision a phone for that user?


> Question: How would we be able to reboot a single phone when 
> they are all registered to a common account? 

The check-sync NOTIFY message will be addressed and sent only to the
single phone.  i.e. "[email protected]", not
"[email protected]".

(This feature will introduce a 1:1 association between a phone's MAC and
its IP address.  Once that is in place, then sipXconfig could start
rebooting only single phones as well.)
 

Tony wrote:
> Perhaps a separate range of "lines" can be allocated to a 
> "provisioning group". 

We won't need separate "lines" just to keep the other un-provisioned
phones from rebooting.  

Note that the common provisioning account will not show up as a User in
sipXconfig.
 

> At the same time, if the 
> provisioning AA function can reverse the step (I am user 201, 
> I no longer wish to use this phone, please de-register me), 
> it can essentially perfrom a basic hotelling feature.
> I think a lot of this pieces in XX-6490 go a long way to 
> possibly fulfilling XX-4987 in a basic way.

Agreed.


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

Reply via email to