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
