See answers embedded below:
-----Original Message-----
From: Huijun Yang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2008 1:50 PM
To: Paul Mossman; Dutkiewicz, Marek; [EMAIL PROTECTED]
Subject: RE: [sipX-dev] Polycom SoundPoint IP Config Files and sipXecs
> 4. Preserving the sip.cfg and phone1.cfg files This is STRONGLY
> RECOMMNEDED practice. Polycom cannot guarantee that some parameters
> might change between releases that can cause subtle problems - the
> most obvious real issues from the past were some audio settings which
> caused poor audio quality if they were not updated between releases.
> We'd like to clean this up, but where we are now with the number of
> models of phones and different releases out in the field we can only
> test and guarantee proper performance if the software and
> configuration files are matched.
> 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.
Another area that has recently undergone some change is the 'LineSeize'
behavior (i.e. what happens when I lift the handset does it grab a new
line to make a call or attempt a call on the current line. For some call
servers this behavior is important. These are: call.stickyAutoLineSeize
(in sip.cfg)
The intention is that new default settings preserve previous behavior
and the code should have built in 'null' defaults that retain previous
behavior. However this is not a rule that is rigorously tested.
This design has some history behind it and we are planning to clean it
up such that parameters that should not be user/administrator changed
are built in to the code, but this will take some time to achieve
especially since we require maintenance of backward compatibility.
> We are struggling with this recommendation. The issue is that
sipXconfig facilitates configuration of so many Polycom > SoundPoint IP
parameters. In doing so, our code replicates the default value for
each, so that they can be displayed > in sipXconfig and included in the
generated profile.
> 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
Another question to Marek, if the order of the configuration files is :
<mac>.sip.cfg, sip.cfg, phone1.cfg, my understanding is that for any
parameter, if parameter value can be found in <mac>.sip.cfg, then it
will be picken up, and the value for the same parameter defined in
sip.cfg will be ignored. Is it correct? For parameters defined in
<mac>.sip.cfg, does it have to use <OVERRIDES> tag as shown below:
[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
<?xml version="1.0" standalone="yes"?>
<PHONE_CONFIG>
<OVERRIDES lcl.datetime.date.longFormat="0"
lcl.datetime.date.format="Md,D" reg.1.ringType="4"
voIpProt.SIP.musicOnHold.uri="sip:[EMAIL PROTECTED]"/>
</PHONE_CONFIG>
Thanks
Huijun
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
