Huijun Yang wrote: > Given there are hundreds of configuration parameters, > and trying to manually keep a partial clone of what > Polycom has in the default configuration files in > sip.cfg.vm and phone.cfg.vm is just error prone, not > to mention that Polycom may change, add/remove > parameters in future releases. Instead of trying to > address these problems at one shot, we would like to > make the improvement and move to the middle ground by > solving issues 1 and 2 for sipXecs 4.0 release. I > would propose that we include Polycom latest default > configuration files, and for those parameters that are > not settable from the UI and are currently hard-coded > in sip.cfg.vm and phone.cfg.vm, we will remove those > and have them picked up from Polycom default > configuration files. In this way, we are assured that > the default values for those parameters are correct > and expected. Again, this still is not an ideal > solution, as it does not address issue 3, to support > multiple versions of Polycom firmware, but the issue > exists today. > > The JIRA issue related to this is http://track.sipfoundry.org/browse/XCF-2751 > > I'd like to get others' opinion on this.
I am (not surprizingly) in favour of it. We will still "lock" each of our releases to a particular version of Polycom firmware. i.e. The version whose sip.cfg and phone1.cfg files we've tested with and included in the release. This differs from the original proposal in that activating a new firmware package (under "Device Files") will *not* change the sip.cfg or phone1.cfg content picked up via our generated profiles. What I like most about the approach is how much easier and less risky it will be to handle each new Polycom firmware release. You start with a diff between the new sip.cfg/phone1.cfg and the previous versions already checked into subversion. This instantly shows you exactly what has changed between the new and "locked" Polycom firmware versions. (This doesn't work today because our sip.cfg.vm and phone.cfg.vm contain too many Velocity-related items.) You then investigate each difference and determine whether it: - will be exposed for configuration (therefore included in the overrides); OR - will not have its default value overridden (therefore not exposed for configured); OR - will not be exposed for configuration, but must have its default value overridden. (An example of the latter is the new Music On Hold URI.) No more manually searching for changes. No more changes falling through the cracks. That work will also make it easier to evaluate the compatibility of new Polycom firmware releases with profiles generated by the currently shipping versions of the product. We'll quickly be able to come to the conclusion that, for example: "Polycom firmware 3.1.0 Rev B is compatible with version 3.10.1 of sipXecs, with the following limitations: 1. The new Music On Hold feature will not be active. 2. The new BLF "ringing" indication (flashing green LED) will work. But when a target is on a call and receives a second call the LED will become unlit, instead of flashing between lit green and lit red as it should. 3. etc...." Yes, let's get this done. -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
