Some comments to help explain the reasoning behind some of the recommendations (I am a Product Manager with Polycom). I look forward to further discussion on this thread.
Firstly I would like to commend the Pingtel developers on the job they have done to implement and maintain 'Plug-And-Play' support for Polycom phones on the sipXecs platform. I have received good feedback from sipExcs/Polycom users on this topic. Hopefully we can continue and enhance this. 1. Support for different software versions on different phones: The IP 300 and IP 500 devices have been 'grand-fathered' on the SIP 2.1.x (latest is 2.1.3) software release. They ran out of memory to be supported in SIP 2.2 and newer. The IP 301 and 600/601 devices were recently 'End of Sale'd and you should anticipate that these may be grandfathered on a release soon. Hence in BootROM 4.0/SIP 2.2 some new 'macro' style references to phone models were added to ease the job of supporting legacy phones on newer software releases. Whilst this may not be a must have right now it is a good thing to get prepared for. 2. Using 000000000000.cfg instead of separate <MAC-ADDRESS>.cfg files This is tied to 1) above, and also relates to managing files. If a unique file is created for every phone, and you get up to several thousand phones and you then decide you want to set something special for a particular model of phone you're going to be faced with a challenge. The use of the phone model and MAC ADDRESS substitution capability makes the applying of model specific configuration settings significantly easier. 3. Writing the Preferences (<MAC-ADDRESS>-phone.cfg) (and also Directory) files to the provisioning server. The internally saved user preferences and directory settings are erased if the Flash File System is re-formatted. This will occur if the BootROm software is upgraded. It is vastly preferable to have these parameters saved on the server. Another use case might be where a phone is RMA'd. The user preferences and directory can be easily restored by renaming the files to the MAC-ADDRESS of the new phone. The security concerns are valid, although the server that is used for this purpose can be completely different to the call server itself - the 000000000000.cfg file can specify a different directory, path or server name for the contacts, overrides(preferences) and log files to be written. 4. Preserving the sip.cfg and phone1.cfg files This is STRONGLY RECOMMNEDED practice. Polycom cannot guarantee that some parameters might change between releases that can cause subtle problems - the most obvious real issues from the past were some audio settings which caused poor audio quality if they were not updated between releases. We'd like to clean this up, but where we are now with the number of models of phones and different releases out in the field we can only test and guarantee proper performance if the software and configuration files are matched. Looking forward to further interactions - we have some significant sipXecs enhancements coming in our SIP 3.1.0 release due out at the end of August. Marek -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Damian Krzeminski Sent: Friday, August 01, 2008 2:33 PM To: [EMAIL PROTECTED] Subject: Re: [sipX-dev] Polycom SoundPoint IP Config Files and sipXecs Paul Mossman wrote: > Hi all, > > I was advised to read the following Polycom document regarding > Configuration File Management on SoundPoint IP Phones: > _http://www.polycom.com/common/documents/whitepapers/configuration_file_ management_on_soundpoint_ip_phones.pdf_ > > > There were a number of surprizes for me. I think we should look at > these recommendations, and seriously consider moving towards complying > with them, or at least finding some middle ground. > We tried to comply with them in the past (see subversion history and many closed JIRA issues on Polycom). In many cases it just does not work. Documentation says one thing and the phone does its own thing. I am all for making the changes that would make us more compliant but in many instances there is a reason why we are not. > > - The document recommends that you no longer use per-phone <MAC>.cfg > master configuration files, but rather use a single 000000000000.cfg > master configuration file instead. (Polycom phones first attempt to > retrieve a <MAC>.cfg file. If that can't be found they attempt to > retrieve a 000000000000.cfg file.) But I think this needs to be taken > with a grain of salt, because Example 1 in the doc uses a > 0004f2000607.cfg file. > > > - The document also states that the sip.cfg and phone1.cfg files > distributed with the firmware should not be modified. ("Making > modifications to the original configuration files will make future > software upgrades difficult.") We don't even supply them by default in > our installations. How could we, since our distributions not tied to a > single Polycom firmware version? We could point each version to a different directory or server? > > Instead we generate per-phone <MAC>-sipx-phone.cfg and > <MAC>-sipx-sip.cfg files, which are based on firmware-version-specific > templates. The user then chooses the appropriate firmware version when > adding a Polycom phone. > > This allows us to support installations with mixed version of Polycom > firmware. Though I'm not sure how useful that is, since all phones get > upgraded once newer firmware is found on the boot server... (Except the > 300 and 500 model phones with the memory size limitations. This is > handled by the APPLICATION_SPIP300 and APPLICATION_SPIP500 lines in the > master configuration file.) > > On a related note, I was looking at the changes for XCF-2517: support > Polycom 3.0 firmware... I was expecting to find 3.0 template files in > sipXconfig/neoconf/etc/polycom/mac-address.d/, but only the 1.6 and 2.0 > ones are present. Does anyone know why that is? > > > - The document also states "Do not use <MAC>-phone.cfg for any new > configuration files. This is the name of the configuration override file > generated by the phone when the user changes a setting such as the > preferred ring type." > > Yes, each time a user preference is changed on the phone, the phone will > attempt to FTP this config file to the boot server! This doesn't work > on our RPM-based installs, since the PlcmSpIp user by default does not > have write access to the FTP server. Probably a good idea, since you > don't want effectively public credentials to have write access to your > call server. > > Also, I'm not quite sure why the phone does this, since it retains the > current settings after a reboot if this file does not exist. (The > current settings even take precedence over the values found in the other > configuration files.) Perhaps it is purely to allow the possibility of > the user's selections being viewed/modified remotely? Modification > seems odd, because a user modification would override any changes made > on the boot server that have not yet been picked up by a phone reboot. > In either case, it is not something sipXecs Plug & Play uses. > > > - Example 1 in the document is interesting. The per-phone master > configuration file lists: > - 0004f2000607-user.cfg > - local-settings.cfg > - phone1.cfg > - sip.cfg > > The phone1.cfg and sip.cfg are assumed to be taken unmodified from the > firmware release. The local-settings.cfg file is per-site, and contains > only site-specific settings that override those in sip.cfg. Likewise > 0004f2000607-user.cfg contains per-user settings that override those in > phone1.cfg. > > One interesting thing to note is that the "digitmap" setting is > considered site-specific, where sipXecs instead considers this a > per-user configuration setting. Having it site-specific would certainly > make it easier to maintain a correct value... I am not sure what they mean by site-specific. In sipXconfig you can configure any configuration value on a group level. This is way more powerful that site vs. phone specific distinction. > > After cautioning against modifying phone1.cfg and sip.cfg, the document > goes on to say that you need to review the release notes for new > firmware to check for changes to configuration parameters that are not > backward compatible with what you're using in your existing > site/user-specific files. This isn't a new problem. But if we were > using the Example 1 approach things would be simpler in two ways: > > 1. Our "review" would be simpler: We'd only be generating overrides, > so we'd have a smaller set of parameters to check. > > 2. We'd have a better change of being compatible with future firmware > versions: Non-backward compatible changes to parameters that we do not > override would require no changes on our part. (I think such a case > occurred in moving from firmware 1.4.0 to 1.5.3...) > This is more or less how it worked until 3.8 if I remember correctly. Around 2.0 firmware the overrides just stopped working. I spent a week or two trying to figure out what's wrong and then decided it's just not worth it. > > - Example 2 shows how to specify which model should load which version > of firmware. I don't think we have a good use case for this, in which > case we shouldn't consider it. (Note: This isn't the 300/500 problem, > where those models do not have enough memory to hold post-2.1.3 firmware.) > > > Comments? Those are one of the worst phones to configure. The file format gives people headaches, the parser is picky, the background compatibility is laughable, the SIP standard treatment is... well I'd rather not comment. I cannot imagine configuring and maintaining Polycoms *without* sipXconfig. But they have a lot of features and both users and administrators like them. I think this is a very important plugin to maintain and we should add new features to it, improve it and keep it current. But I am cautious about any changes that are made just to comply with current version of ever-changing docs. I'd rather keep on fixing problems on case by case basis. Also - since Douglas does not work on this any more, it's a plugin in search for a proud parent. If you submit enough patches, you'll find a nice e-mail from me in your mailbox one day suggesting that you just take over ;-) > > Thanks. > > -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 _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
