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.