18 Oct
2013
18 Oct
'13
9:14 a.m.
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
20 Oct
20 Oct
4:10 p.m.
New subject: Patch: Respect Order field in NAPTR, as required by RFC 2915
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(a)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; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
29 Oct
29 Oct
4:34 a.m.
New subject: Patch: Respect Order field in NAPTR, as required by RFC 2915
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(a)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 -
11 Nov
11 Nov
8:48 a.m.
New subject: Patch: Respect Order field in NAPTR, as required by RFC 2915
On 2013-10-29 at 09:34, Daniel-Constantin Mierla wrote:
Fixed in the new patch.
--
Øyvind Kolbu
On 10/18/13 3:14 PM, Øyvind Kolbu wrote:
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.
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. 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.
5:38 p.m.
New subject: Patch: Respect Order field in NAPTR, as required by RFC 2915
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:
Fixed in the new patch.
_______________________________________________
sr-dev mailing list
sr-dev(a)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 -
On 10/18/13 3:14 PM, Øyvind Kolbu wrote:
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.
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. 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.
12 Nov
12 Nov
3:58 a.m.
New subject: Patch: Respect Order field in NAPTR, as required by RFC 2915
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.
--
Øyvind Kolbu
9:55 a.m.
New subject: Patch: Respect Order field in NAPTR, as required by RFC 2915
Hello,
On 11/12/13 9:58 AM, Øyvind Kolbu wrote:
On 2013-11-11 at 23:38, Daniel-Constantin Mierla
wrote:
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
--
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 -
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.
13 Nov
13 Nov
4:11 a.m.
New subject: Patch: Respect Order field in NAPTR, as required by RFC 2915
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:
- http://www.kamailio.org/wiki/cookbooks/devel/core#dns_parameters
Thanks! Will update docs.
--
Øyvind
4065
days inactive
4091
days old
7 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Øyvind Kolbu