[sr-dev] Patch: Respect Order field in NAPTR, as required by RFC 2915
Øyvind Kolbu
oyvind.kolbu at usit.uio.no
Fri Oct 18 15:14:16 CEST 2013
Hi,
Kamailio's NAPTR behavior by default ignores the Order field, which it is
not allowed to do. Excerpt from RFC 2915:
Order
A 16-bit unsigned integer specifying the order in which the NAPTR
records MUST be processed to ensure the correct ordering of
rules. Low numbers are processed before high numbers, and once a
NAPTR is found whose rule "matches" the target, the client MUST
NOT consider any NAPTRs with a higher value for order (except as
noted below for the Flags field).
Currently one can set dns_{udp,tcp,tls,sctp}_pref to the same value and
then it will respect the Order field. This has the problem that the SRV
lookup order is forced to udp, tcp, tls and sctp.¹ Hence you can not
follow the RFC for NAPTR and also set your own priorities for SRV. E.g. I
want to have tls -> tcp -> udp and adhere to the NAPTR.
Made a core option, dns_naptr_ignore_rfc, default off, to preserve today's
behavior. See attached patch.
One implementation detail is that one currently can disable a protocol
by setting the priority to -1. In my patch that is currently ignored.
Can add a check for that in init_naptr_proto_prefs() before setting
a protocol's preference to 1.
¹ Mandated by the order of ip_addr.h's enum sip_protos.
--
Øyvind Kolbu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dns_naptr_ignore_rfc.patch
Type: text/x-diff
Size: 8932 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20131018/b11e9cdc/attachment.patch>
More information about the sr-dev
mailing list