Hi Øyvind,

On 10/18/13 3:14 PM, Øyvind Kolbu wrote:
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.
did I get it wrong or the dns_naptr_ignore_rfc has to be 1 (on) to preserve current behaviour? You said 'off' (expect 0) which collides with the 'ignore' in the name of the parameter.

 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.

Can you add the check for ignoring a protocol? Sometime it might be needed. Resend the patch and I will push it to repo.

Thanks,
Daniel


¹ Mandated by the order of ip_addr.h's enum sip_protos.




_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28
  - more details about Kamailio trainings at http://www.asipto.com -