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. I agree on these risks. This approach is based on the assumption that Polycom is smart enough to fill the gaps for the parameters not generated by sipXconfig, which is claimed by Polycom. > Is it a good time to move the plug-in into its own directory? I think it is a good opportunity to do clean the house. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
