> > >-----Original Message----- >From: [email protected] [mailto:sipx-dev->[email protected]] On Behalf Of Krzeminski, Damian (BL60:9D30) >Sent: Friday, September 11, 2009 3:24 PM >To: [email protected] >Subject: Re: [sipX-dev] Automated phone provisioning - XX-6490 > >Paul Mossman wrote: >> >> Damian wrote: >> ... >>> 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. >> >> What is the use case for having discovered phones inherit configuration >> from a Group? > >It's the most natural way of letting admin to provide configuration for a >newly discovered phone. If phone gets tagged automatically with a group >that admin specified, admin has an easy way to provide default config for >phones that are not manually added.
This is a great idea. We could define a dedicated group for un-provisioned (discovered) phones. That group could include the calling permissions and other things we can configure at the group level. Would we need such a group added as a new default group in the system? > >> >> My hope is that we could filter for unprovisioned Phones without a >> Group. i.e. Add "-unprovisioned-" between "-all-" and "-search-". Only >> Phones with exactly zero Lines assigned would show up under this filter. >> This filter would be most useful under Users->xxx->Phones->Add existing >> phones. >> >> >>> 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). >> >> Only works if sipXecs is the DHCP server, right? That isn't always the >> case. I'm told lots of sites use some Microsoft product... >> >> I think we want something that works regardless of which server (if any) >> is providing DHCP. >> > > >I am not advocating that analyzing dhcpd logs would become the only way of >discovering new devices. It's just an example. Plug-in based discovery >allows for wring discovery modules for many services. Probably also for MS >DHCP. > We cannot make any assumptions around where the DHCP server runs. This has to work independent of whether sipXecs provides DHCP or any other host somewhere on the network. One key objective is to get this to work across a routed network. Retrieving and analyzing DHCP logs from different DHCP servers will not work. --martin _______________________________________________ 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/
