I still believe all those things should be kept for one reason: sipX has 
the ability to provision external lines. External as in not on a sipX 
system. Some of the settings that are being suggested for removal may be 
crucial for operation on an external system. One other thing should be 
realized as well: while simplification is a good thing and makes 
everyones lives easier, how much is too much? How much do things get 
watered down before they become so basic that monkeys banging on 
keyboards can make the system work.

My opinion is don't take anything out, but consider reorganizing the 
configuration and just throw all the "unnecessary" stuff under an 
advanced area.

And please implement the polycom custom xml patch that Eric Varsanyi 
wrote. It would be extremely useful for large complex installations 
(like mine).

Josh Patten
Assistant Network Administrator
Brazos County IT Dept.
(979) 361-4676


On 5/6/2010 12:02 PM, Mossman, Paul (Paul) wrote:
> 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/

Reply via email to