I wanted to throw some thoughts together with regards to Polycom version 3.3 and above to help maybe settle some design criteria for moving forward. I'll lay out the issues at hand, and then some suggestions on things that will need to be decided on to move forward. This certainly is not all inclusive, so please add in as you see fit.
Polycom 3.3 and above is a completely different beast. For one, the firmware now comes with defaults for most all perameters, so there is no need to create a lot of the values in their configuration file. There are also significant changes to the firmware that all changes without necessarily rebooting the phone, and some changes work on the fly. Phones that are running version prior to 3.3 need to load a special firmware that converts them to work with then newer files. Without this, it pretty well messes the phones up. New models of phones from Polycom come with version 4.0.1 now, so in order to support this, changes are necessary within sipXecs. Even some of the phones supported in the past, such as the Polycom 335 are now released as the Polycom 335C and require the new firmware. It is just a matter of time before someone runs into this issue. The Polycom's look for a file called [mac].cfg in the TRFT root first. If it doesn't find a cfg file, then it looks to a default of 000000000000.cfg. Within this file currently, there are some parameters defined for loading some of the old firmware files into older models of Polycom. This method essentially allows for running several versions of firmware on the system. I believe that file can be further modified to create model specific files for configuration of phones running the new firmware. For example, adding code to cause the phones to look into a directory with their model name, and then their [mac].cfg file. This accomplishes a few things. First, it puts the configuration files for all of the same model into one directory, along with its current firmware and organizes things a bit. Secondly, it allows these phones to pull their specific firmware, while older legacy phones can continue to pull their firmware from the TFTP root, or another directory all together. I'm currently doing this manually, and it works rather well. Manually in that I move the files to the correct directory manually, but the phones find them automatically via the modified 000000000000.cfg file. This could actually allow for using one firmware with one particular model, while using a different version with another model phone. I believe this is manageable, and is actually a smaller task that originally thought. Question for the list - is there wisdom in breaking things out into different folders like this, or is it just added complexity? Is this beneficial for large installations? I believe we need to get started on this sooner rather than later. I will create the Jira's necessary to get things tracked. I would like to hear opinions regarding the method for managing the transition from current firmware files, and management of phones running on the new firmware. Polycom phones have served sipXecs well over the years, I believe we need to ensure that continues.
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
