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.
Hello,
thanks for the patch, I will look over it soon.
Cheers, Daniel
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. 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
On 2013-10-29 at 09:34, Daniel-Constantin Mierla wrote:
On 10/18/13 3:14 PM, Øyvind Kolbu wrote:
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.
Hi and sorry for the late reply. Been offline on vacation.
Yes, the value has to be 1 to actually ignore the rfc. The code was correct, but the default value not. Fixed in the 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.
Fixed in the new patch.
Hi Øyvind,
thanks for update -- I didn't find the time to follow up the discussion as well.
I tried to apply the patch, but apparently it is not for master branch. Some chunk fails to apply. Can you update it for master branch?
Cheers, Daniel
On 11/11/13 2:48 PM, Øyvind Kolbu wrote:
On 2013-10-29 at 09:34, Daniel-Constantin Mierla wrote:
On 10/18/13 3:14 PM, Øyvind Kolbu wrote:
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.
Hi and sorry for the late reply. Been offline on vacation.
Yes, the value has to be 1 to actually ignore the rfc. The code was correct, but the default value not. Fixed in the 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.
Fixed in the new patch.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 2013-11-11 at 23:38, Daniel-Constantin Mierla wrote:
Hi Øyvind,
thanks for update -- I didn't find the time to follow up the discussion as well.
I tried to apply the patch, but apparently it is not for master branch. Some chunk fails to apply. Can you update it for master branch?
OK, updated for master now. Previously was on 4.0.
Hello,
On 11/12/13 9:58 AM, Øyvind Kolbu wrote:
On 2013-11-11 at 23:38, Daniel-Constantin Mierla wrote:
Hi Øyvind,
thanks for update -- I didn't find the time to follow up the discussion as well.
I tried to apply the patch, but apparently it is not for master branch. Some chunk fails to apply. Can you update it for master branch?
OK, updated for master now. Previously was on 4.0.
thanks, patch applied on master branch. Would you mind adding the appropriate docs to wiki:
- http://www.kamailio.org/wiki/cookbooks/devel/core#dns_parameters
Cheers, Daniel
On 12.11.2013 15:55, Daniel-Constantin Mierla wrote:
thanks, patch applied on master branch. Would you mind adding the appropriate docs to wiki:
Thanks! Will update docs.
-
Daniel-Constantin Mierla -
Øyvind Kolbu