We have investigated issues with the Buddy Watch and BLF functions with various versions of SIPxchange and Polycom firmware. We have found (and reaffirmed by Polycom) that issues arise with these functions if you do not use the sip.cfg and phone1.cfg templates provided in the firmware .zip file with the version of sip.ld in the phone. With v3.8 which used the "per phone" overlay implementation, we could resolve the issues by copying the templates into the sipXconfig directory where the templates used to generate the phone configuration files are located.
We just upgraded one of our lab systems to v3.10.2. I upgraded the Polycom firmware to sip.ld v3.0.3b and bootrom v4.1.1 and generated new configuration files for all phones. We have a 601 with 1 expansion module configured with 6 lines and 2 speed dial entries set to monitor presence on a Polycom 430 and 501. BLF is not functioning for the two phones on the expansion module. We have also configured the system to use the Buddy Watch function instead of BLF. That also did not work. I suspect a template mismatch, but need to research a little further before submitting the documentation on the issue. Therefore, I also recommend the per phone overlay method. Sincerely, Dave Deutschman Managing Partner Innovational IP Solutions, LLC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Mossman Sent: Tuesday, August 05, 2008 12:14 PM To: [EMAIL PROTECTED] Subject: Re: [sipX-dev] Polycom SoundPoint IP Config Files and sipXecs Kevin wrote: > The 3.0 firmware shares a compatible file structure with the 2.0 > firmware. Therefore, we are able to use the same (2.x) velocity > template to generate the configuation Could we remove/suppress the "Firmware Version" setting at this point? I think it is safe to assume that we do not support this version anymore. I also notice the unit test directory for Polycoms have "expected" sip/phone cfg.xml files for 2.0, 2.1.2, 2.2.0, 2.2.2, and 3.0.0. Most of the differences seem to be formatting, but some are not. Why are these required? (I can't see how sipXconfig could target different versions within "2.0"...) Note that IP 300 and IP 500 devices that cannot be upgraded past 2.1.x. We don't need a "Firmware Version" setting to accommodate this, since it could be implicit in the selection of the phone model. We'll need to handle when there is a configuration file change that will not work with 2.1.3. (I don't think we have any yet...) Of course, to do the above we'd have to break apart the 300/301 and 500/501 options under "Add new phone..." But could some of the options actually be consolidated: 550/560 and 650/670? Damian wrote: > Paul Mossman wrote: >.... > > - 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? By specifying a different server/directory in the <MAC>.cfg file, I see now. Though I don't think we have a business justification for supporting multiple version of Polycom firmware at the same time. (Especially considering the complexity it would add to the "Device Files" page.) Anyone disagree? > I am not sure what they mean by site-specific. In sipXconfig you can > configure any configuration value on a group level. I see what you mean. > > 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. With Polycom's assistance, let's move back to that approach. (Using the phone1.cfg and sip.cfg files from the Polycom firmware, and generating per-phone overrides only.) I think the pending Polycom plug-in changes to support 3.1 firmware and the Productivity Suite justify it. Marek wrote: > 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. Ah, the example in the Administration Guide makes this more clear. We could have a single 000000000000.cfg file with the [PHONE_MAC_ADDRESS] macro, instead of many <MAC>.cfg file that differ only by the MAC address inside them. > 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. I like the idea, and I see now from the Administration Guide that you can specify a URL to specify alternate directory, server, username and password. The Administration Guide isn't clear though, does the CONTACTS_DIRECTORY attribute governs preference? Perhaps we could add a new ftp user with write privileges and a dedicated /var directory for storing CONTACTS_DIRECTORY and LOG_FILE_DIRECTORY files? If that is still too risky, then we could allow an administrator to specify an alternate server, similar to Backup/Restore FTP Configuration. Thanks. -Paul _______________________________________________ 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
