-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Krzeminski, Damian (BL60:9D30) Sent: Wednesday, October 01, 2008 11:29 AM To: [EMAIL PROTECTED] Subject: Re: [sipX-dev] Proposal for Polycom Plug&Play changes to use Polycom default configuration files
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? The relevant default configuration files are sip.cfg and phone1.cfg. As Paul suggested, in order to avoid customer picks up wrong version of default Polycom config files with same names, we need to choose the version we are going to use for 4.0 release, and rename the two files to something like: MATCHED_polycom_sip.cfg and MATCHED_polycom_phone1.cfg ( or if anyone can provide a better name). The two files need to be kept under svn. The place I would suggest is sipXconfig/plugins/polycom/etc, the new plugin place for Polycom. We need to somehow hook it to the installation process for both production and development environment so that the two files can be programmatically copied to the tftproot when system gets installed. I'd like to get experts' opnion on how to achieve this. Thanks in advance! Huijun _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
