I agree with Scott. We should not make it more difficult to manage an environment where a sipXecs Admin is forced to support multiple versions of Polycom firmware. sipXecs needs to be able to support use of multiple versions of active firmware.
The format of the <mac-address>.cfg file provides the ability to deploy the files for each activated version of firmware in sub directories of tftproot. The Admin should be able to select which version of activated firmware to use when creating or updating a phone group or individual phone. When Send Profiles is clicked, sipXecs should then generate configuration files in the format required by the selected version of active firmware. DD -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Scott Lawrence Sent: Saturday, January 09, 2010 7:38 AM To: Paul Mossman Cc: [email protected] Subject: Re: [sipX-dev] Handling firmware for Polycoms in a mixed legacy/non-legacy environment On Thu, 2010-01-07 at 12:59 -0500, Paul Mossman wrote: > Hi all, > > Polycom 301, 501, 600, 601, and 4000 were deemed "legacy" as of 3.2.0. > This means they will only be supported in 3.1.X. Previously this was > 3.1.3, but 3.1.4 has recently been released. > > (Polycom 300 and 500 are only supported in 2.1.X.) > > This presents a challenge when sipXecs is deployed with a mix of > legacy and non-legacy Polycoms. > > The configuration file generation is actually handled very well now. > > > Firmware deployment on the other hand, is not. See: > http://list.sipfoundry.org/archive/sipx-users/msg17596.html > > Scott and I once talked about a graceful solution, but it is certainly > will not go into 4.2. > > > I'd like to propose a solution that is nearly as good, but easy to > implement. > > Basically, Polycom configuration files can specify which firmware > files should be loaded on a per-model basis. All models are currently > directed to use "sip.ld", which is the default filename used in the > "current" Polycom firmware ZIPs. The sip.ld will simply not load on a > Polycom that does not support it. > > The legacy models will be told to pick up say filenames "sip_31X.ld" > or "sip_21X.ld". That is the easy part. > > Unfortunately the "legacy" Polycom firmware ZIPs don't use consistent > names for the sip.ld file. So, it would be challenging to handle them > gracefully like we do for the "current" ZIPs. I think the best option > is simply to have the superadmin extract the file from the ZIP, rename > it ("sip_31X.ld" or "sip_21X.ld"), and then upload it as an "Unmanaged > (T)FTP file". > > The superadmin will have some extra work, but it'll make life > considerably easier than no solution at all. This sounds suspiciously like: Let's make life a little easier for a few developers who have deep knowledge and a little more complicated for a lot of system admins who don't. Doesn't sound like a recipe for customer satisfaction to me. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
