[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