Re: [sr-dev] Patch: Respect Order field in NAPTR, as required by RFC 2915

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. _______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev