Paul Mossman wrote: > 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] > >
Understandably I am not as optimistic as Paul, but as long as it actually works (that is as long as values in the generated file really do overwrite the values in the template) I do not really have anything against it. Let's remember - as Paul points out - it's not like there is a magical approach that makes sipXconfig support multiple versions of firmware just by dropping a new Polycom templates. There are some risks with this approach: generating and testing a single complete file is simpler than generating a file to be overlayed on some other file, but looks like you and Huijun are effectively taking over Polycom plug-in development and have all the rights to take this risk. Is it a good time to move the plug-in into its own directory? 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
