Mike wrote: > I figured that's how we'd have to do it... I just wasn't > sure if the dev team was hatching a scheme for multiple > versions of Polycom firmware being active on the PBX.
Scott and I have talked about how to do it, but there are currently no plans. I can open a JIRA, but let's first get crisper about what's required. I think we'd have to resurrect the "Firmware" field for Polycoms. It would affect the content of the generated config files (as it did before.) But it would also now control which release of firmware that sipXecs directs the Phone to use. There are too many Polycom releases to support them all at once. We would want to support the latest "non-legacy" release, as well as the latest legacy 3.1.X (for the 301, 501, 600, 601, & 4000s.) The latest legacy 2.1.X would only be useful for 300/500s. Are there many of those still in active service? Also, you don't want to upgrade your Polycoms all at once. More specifically, when you are upgrading some Polycoms, you don't want to rely on crossing your fingers and hoping others do not reboot (and thus upgrade unintentionally.) I think this means that each sipXecs release should support two "non-legacy" releases: the current Polycom release, plus the latest Polycom release from the previous sipXecs release. So, each sipXecs release would drop the older Polycom firmware, but add a new one. All Polycoms running the pre-upgrade latest, will be running the oldest after the upgrade. You will then need to manually change the Firmware values of Polycoms in order to upgrade them. To avoid surprizes, you will need to be running the latest Polycom firmware before a sipXecs upgrade. (Because the pre-upgrade latest will become the post-upgrade oldest.) The pre-upgrade oldest will be removed. Any Polycoms that had the pre-upgrade oldest Firmware value selected would be changed to the post-upgrade oldest value. If that is activated, then those Polycoms would immediately undergo a firmware upgrade. Some other concerns I have with this approach: 1. Upgrading Polycom firmware will become more manual that other phones. Would the inconsistency be too confusing? Would it be too inconvenient? (Though, a default "all" Phone Group would remove much of the inconvenience.) 2. I don't think sipXecs can (or should) check that you're uploading an exact match of the firmware version you've selected. 3. It is less simple. When a new superadmin sets up the Polycom firmware on a new system, there will be an increased chance for error. You'll need to match the version under Device Files with the version selected under Phones. If there's a mismatch, then Polycoms won't pick up the firmware. You may not notice. If you do notice, you may not immediately understand what the problem is. 4. Likely there'll be a few Polycom release between the two that we support in any given sipXecs release. This may seem odd to new users. Why for example, would we support 3.1.3RevB and 3.2.2, but not 3.1.3RevC, 3.2.0, and 3.2.1? Thoughts? -Paul [email protected] _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
