Paul Mossman wrote: > > Martin wrote: > ... >>>> Once a Polycom is discovered, a Devices->Phones entry is >> created with >>>> the MAC and model set, but no Lines assigned. >> +1 So it sounds like the model is discovered as well and no >> longer needs >> to be manually entered from a drop-down > > Precisely. > > >>>> To be clear, the discovered phones will not show up under >> Devices -> >>>> Discover Devices, nor will they be put into any Groups. >>>> >>> I don't like it. No matter how the phone is discovered it should be >> added >>> to Discovered Devices. >> I agree with that. What we could do is distinguish in the >> table of discovered devices between those that registered and >> those that did not. >> That could be done by either separating it in the table or >> even bettwe with a little green icon that almost looks like a >> "presence" icon and indicates that the phone registered. > > Is this a deal-breaker for Phase 1? It would add to the development > effort, of course. > > Regardless, I do not see the merits of mixing these two features. If > your Polycoms have been auto-provisioned into Devices->Phones, then why > would you want to see them under Discovered Devices?
We talked about marrying discovery and auto configuration before and if done properly it's a nice vendor independent feature. You cannot really blame me for trying to steer that into direction that be beneficial for other types of phones, right ;-) But of course if you want to test something Polycom specific and if that won't clash with current discovery that's a different matter. That might be a good first step regardless of other considerations. > > We can avoid using the term "discovery" for this new feature if it makes > things more clear. (Really sipXecs is not discovering phones, simply > auto-provisioning those that have asked it for their configuration.) > > Yup. I think if we stay away from mentioning "discovery" it would be less confusing. If this is a Polycom only special that does not require or introduce any UI to deal with configuring un-provisioned phones than I am fine with it. I am only against introducing concepts parallel to those that we already have. D. _______________________________________________ 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/
