> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dutkiewicz, Marek > Sent: August 14, 2008 2:01 AM
Thank you very much for your valuable comments Marek! > > Marek: Can you tell us what those audio settings were? Can you also > > advise what items might encounter a similar problem in the future? > > In particular, are frequently configured items at risk? Would > > the absence of newly added parameters be likely to cause a problem? > > [mkd] There are a variety of audio settings in the sip.cfg file. These > fall mostly under voice.XXX.YYY. In particular there are a set of > voice.gain.rx.XX and voice.gain.tx.YY. If you open the template files > included with the release you will see a generic setting and then > several phone specific settings e.g. > voice.gain.rx.analaog.ringer.IP_6000. These settings are used by the > audio developers to 'tune' the phone behavior and should not > be changed by customers as there can be bad side effects of changing > them. However sometimes in a new feature release changes to the audio > algorithms may require changes to the gain settings. If these changes are > not made poor audio performance may result. I would recommend that any > ability to set these be removed from the sipXconfig administrator interface. We are currently exposed to this risk, as there are many voice.gain.* settings in the velocity template file: http://sipxecs.sipfoundry.org/rep/sipXecs/main/sipXconfig/neoconf/etc/po lycom/mac-address.d/sip-2.0.cfg.vm Also: voice.codecPref.*, voice.audioProfile.*, voice.aec.*, voice.ns.*, voice.agc.*, voice.rxEq.*, voice.txEq.*, voice.handset.*, and call.stickyAutoLineSeize.*. Nearly all of these settings are hard-coded, and therefore already not available from the sipXconfig administrator interface, as you recommend. It looks like we have excellent incentive move to the "override" approach. That way we will pick up the above values from the sip.cfg and phone1.cfg files out of the Polycom firmware package. However, our generated files will contain one entry for each parameter exposed in the sipXconfig administrator interface, default value or not. Am I safe to assume these are not likely to suffer problems such as the above two? i.e. Because they are "supposed" to be configured by the administrator? > > If we move to the "override" approach, we will generate one overrides > for every parameter that can be configured in > sipXconfig. Would that essentially nullify the benefit of preserving the sip.cfg and > phone1.cfg files from the firmware? > > [mkd] The recommendation I would make to the sipXconfig team > is that the configuration files are set up such that the <MAC-ADDRESS>.cfg file or > 000000000000.cfg file contains a list of files as follows: > <MAC-ADDRESS>-settings.cfg, site-settings.cfg, sipexcs.cfg, sip.cfg, phone1.cfg A "site-settings.cfg" file for site-specific parameters to override entries in the sip.cfg file? We currently generate a per-phone <MAC-ADDRESS>-sipx-sip.cfg for this purpose. A quick comparison of two on our live trials system shows differences that we do want to have the ability to configure on a per-phone basis: user_preferences up.headsetMode and up.oneTouchVoiceMail, feature.16.enabled (nway-conference), and feature.17.enabled (call-recording). We also allow per-phone configuration of dialplan.digitmap, which is in this file. For sipXecs I propose: <MAC-ADDRESS>-sipx-sip.cfg, <MAC-ADDRESS>-sipx-phone.cfg, sip.cfg, phone1.cfg I think you recommend a "sipexcs.cfg" file for parameters that are sipXecs-specific, but not configurable? Do we have any? If so, I think we handle this by hard-coding the values into velocity template files that are used to generate <MAC-ADDRESS>-sipx-sip.cfg and <MAC-ADDRESS>-sipx-phone.cfg. > [mkd] There is no need to use any <OVERRIDES> tag. The first time any > particular parameter occurs in a configuration file in order > from first > file to last file will be the one the phone uses in operation. E.g. in > your example all settings in <mac>.sip.cfg will take effect. Any that > don't occur in <mac>.sip.cfg will be taken from either sip.cfg or > phone1.cfg I'll take the blame for introducing this confusion. The <OVERRIDES> tag is only used in the <MAC>-phone.cfg file that is generated by the phone to store User Preference selections. (http://track.sipfoundry.org/browse/XCF-2736) -Paul [EMAIL PROTECTED] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
