URL dialing should be moved to Useful. We have customers who have contacts in their phone directories on the phone that are a URI. They do not use the Personal Portal to dial by name. The option could be hidden as an Advanced Setting so we could enable it in those situations but we still need to be able to enable it.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mossman, Paul (Paul) Sent: Thursday, May 06, 2010 10:02 AM To: Lazieburd; Liu, Ke (Ke) Cc: [email protected] Subject: Re: [sipX-dev] Keep deprecated Phone plug-in entries in setting_value DB table? (XX-7815) Douglas wrote: > How can you judge what settings will never ever be used by everyone > who will ever use the system? As soon as you decide "Demux Flag" is > never used, some customer will need to change it and then can't and > entire configuration system is useless. I see four categories of Phone settings: 1. Never useful. e.g. "SIP Settings in DHCP" (XX-5455), NAT, TCP Keep-Alive. The use cases for using these settings with sipXecs do not exist, or are at best far-fetched. The only effect that using them is likely to produce is to break the phone. I'd like to see them completely removed. 2. Almost never useful. e.g. tagSerialNo, Do Not Disturb, RTP filterByIp, URL dialing. You could contrive a use case for any of these. But having none are more important than simplicity. My hope is that these too will be removed, because I think our time is better spent elsewhere. But we can talk about it. 3. Useful, but only with the values dictated by sipXecs. e.g. BLF/MOH URI, NTP, SIP.allowTransferOnProceeding (XX-8030.) There is no need to expose these settings. They should be hidden. (Some can even be hard-coded in the template.) 4. Useful (often, or even only sometimes.) Let's do a good job on these. A really really good job. Good layout and labels. Useful help text. Appropriate GUI widgets. Intuitive and simple. > I do admit the way the settings are displayed it is overwhelming. Yes. The current plug-in is very good at laying out settings in screens and sections that match the config file structure. But deviating from that, and you need to handle the layout-to-config mapping manually. You of course know more about how this works than I do. :) Ke Liu will be starting on the Polycom plug-in soon (XX-8261.) My advice for him is to identify the Category #3 and #4 settings, and concentrate on doing them well. Simplicity will require a manual layout-to-config mapping. That will be the challenge in keeping the Category #2 settings. Perhaps we can have some optional "Advanced" screens for specific Category #2 settings that any community users feel they need enough to provide a patch for? -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/ _______________________________________________ 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/
