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
