> Kevin & Damian: Do you have input on my proposed changes, and questions? > Huijun has been already been investigating, and is ready to start implementing the "overrides" approach, if we have > consensus.
> Actually Huijun also found a challenge regarding default values that I hadn't thought of. He'll post shortly with the > details. If we go for the proposed "overrides" approach, my concern is that we will have to leave all the parameters blank without default values, and let customer to configure/override whatever parameters he/she decides to override the default value provided by Polycom in phone1.cfg or sip.cfg. That way, we can generate a <mac>.cfg that only contains the parameters customer configured. The problem of this approach is that customer will not know what the default value for each parameter is, as phone1.cfg and sip.cfg is not visible through web UI, all it has is a blank form in the UI that contains hundreds of parameters without guidance on default values. I would not like that if I am a customer. One way to solve this issue could be that we load and parse phone1.cfg and sip.cfg provided with the new firmware, and feed the default values to the UI, so that customer will see all the default values being set, then when generating the profile, for each parameter, we have to compare the configured value with the default value from phone1.cfg and sip.cfg again, and only write those parameters whose value changed into the profile... Not sure this is an overkill and if we will run into any trap in this approach. The other question is that how much we gain out of this? The other thing I want to comment is supporting different versions of firmware. Currently, if you look the code, it assumes the firmware is either 1.6 or 2.0. So it uses "unless=1.6" or "unless=2.0" to distinguish parameters applicable for different versions. But that approach will not work any more, as we now have 3.0, 3.1, and more in future. First, I would question why we need to know the firmware version at the first place. For new parameters introduced in newer version, my understanding is that if the phone with old firmware does not recognize them, the phone will ignore it. In other words, profile with new parameters will not harm the phone with old firmware. Maybe my understanding is not true? Welcome your opinion on this. Thanks Huijun I wrote: > 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. To be clear, we could do this, though I don't think we have a reason to in our environment. (Note: The "overrides" capability doesn't apply to this file...) I wrote: > 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? Marek? Grammar corrected: Does the CONTACTS_DIRECTORY attribute govern user preference? I wrote: > 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. I've raised XCF-2736 to cover this enhancement request. 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
