Douglas wrote: > Are you envisioning something like this in the phone group > user interface? > > Polycom - shows setting common to all polycom phones > + Polycom 300 - shows all settings available to the 300 > model + Polycom 301 - shows all settings available to the 301 model
Sort of. Let me give you a use case. Almost all phones have a VLAN ID configuration, and they all do the same thing. Suppose I would like one Phone Group to use a particular VLAN ID. The Phone Group lists all models by all vendors. Right now I need to repeatedly configure the same VLAN ID on just _one_ model for _each_ vendor of the phones in my group. Inconsistent UI treatment makes this especially annoying: - Avaya 12x0s : 'QOS' screen, 'QOS' section, 'VLAN-ID (0-4094)' setting - Polycoms : 'Network Configuration' screen, 'Ethernet' section, 'VLAN ID' setting - G-Teks : 'VLAN' screen, 'VLAN' section, 'Enable VLAN' and 'Identifier (0~4094)' settings - Snom 3x0s : 'QoS and DTMF' screen, 'QoS and DTMF' section, 'VLAN' setting - etc. I'd prefer to instead have a "General" model option in my Phone Group. It would contain all the configuration that works basically the same way on most phones. There would be a "Network" screen, with a "QoS" section, containing a "VLAN ID" setting. This would of course supersede existing screens/sections/settings. So a phone plug-in would need to opt-in to this functionality, with some restructuring, and probably upgrade SQL. The applicable phone models would then have the "General" screens, sections, and settings. But there would also be additional model (or vendor) specific screens, sections, and/or settings. Any "General" screen/section/setting not applicable for a specific phone model would be hidden. My hope is that most of the commonly used phone configuration could be generalized. This would make Phone Groups much more usable. It would also give us a cohesive UI for phone configuration, a valuable improvement even on its own. Does that clarify? George wrote: > IMO an approach would be to merge parent and phone specific > in one XML file using XSLT at build time (though not sure > 100% meets your expectations...) Sounds promising. Could the parent XML be used to deliver the Phone Group "General" model option, as described above? -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/
