" A regular expression seems like overkill, given that the value is
always
supposed to be a number > 0 and <= 1.0."
This is how sipxregistry is written today.
In sipxregistry, SipRegistrarServer.cpp, line 57:
const RegEx RegQValue("^(0(\\.\\d{0,3})?|2(\\.0{0,3})?)$");
In line 1096:
RegEx qValueValid(RegQValue);
if (qValueValid.Search(qvalue.data()))
{
contactUri.setFieldParameter(SIP_Q_FIELD,qvalue );
}
}
Otherwise I am fine with your proposal.
Regards,
Gabor
-----Original Message-----
From: Scott Lawrence [mailto:[email protected]]
Sent: 29 May 2009 14:59
To: Gabor Paller
Cc: [email protected]
Subject: Re: [sipX-dev] Feature proposal: configurable q value regexp
On Fri, 2009-05-29 at 11:36 +0100, Gabor Paller wrote:
> Hi,
>
> I would like to discuss a feature proposal. The motivation is that we
> have some soft phones (e.g. NCH ExpressTalk,
> http://www.nch.com.au/talk/index.html) that registers with
> non-configurable q value (Express Talk uses 0.9). This causes problems
> when used in forking scenarios with other desk phones that use
> non-configurable q-value of 1.0.
That's odd - did you ask them why they use a low value?
> My feature proposal is to make the regular expressions in sipxregistry
> that control the permissible patterns for q values configurable. There
> would be a configuration value in sipxregistry's config file that
would
> override the currently used default regular expressions, when set. It
> would not be set by default.
>
> In the NCH case, the regexp would be set in such a way that value of
0.9
> would be rejected, therefore default 1.0 would be used.
A regular expression seems like overkill, given that the value is always
supposed to be a number > 0 and <= 1.0.
Perhaps just a translation of an incoming q value in a registration to a
value to be inserted in the database? Something like:
SIP_REGISTRAR_Q.NCH : 0.9=1.0
where the part following the dot is variable (so that you can have
multiple entries), and the value specifies that a received q of '0.9' is
changed to '1.0' before being inserted in the database.
It wouldn't surprise me if this causes problems with the phone - it may
not recognize its own contact information in the response if the q value
does not match. You might want to try just hard coding a translation
like the above and test it before fooling with making it configurable.
> I am willing to implement and submit the changes if the feature
proposal
> is accepted by the community.
Another possibility (not mutually exclusive) would be to make a
configuration directive that changed the implicit q value used when none
is specified (most phones don't explicitly send a q value):
SIP_REGISTRAR_DEFAULT_Q : 0.9
which would allow configuration of aliases that take precedence over
registered contacts. This may also have the same interop difficulty.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
