9 Jun
2011
9 Jun
'11
1:44 p.m.
Hi, I'm testing Kamailio's NAPTR resolution:
version: kamailio 3.2.0-dev4 (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
DNS related configuration:
dns_servers_no=2
dns_srv_lb=yes
dns_try_naptr=yes
dns_use_search_list=no
use_dns_cache=yes
use_dns_failover=yes
dns_tls_preference=1
dns_tcp_preference=1
dns_udp_preference=1
As the doc says it should respect the priorities of the NAPTR records,
see
http://kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#dns_sctp_pref_dns…:
"To use the remote site preferences set all dns_*_pref to the same
positive value
(e.g. dns_udp_pref=1, dns_tcp_pref=1, dns_tls_pref=1, dns_sctp_pref=1)"
So my kamailio receives an INVITE for an external domain oversip.net
(no transport param neither port in the RURI) and does a t_relay.
Request RURI is sip:qwe@oversip.net.
According to NAPTR:
~$ host -t naptr oversip.net
oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" ""
_sips._tcp.oversip.net.
oversip.net has NAPTR record 10 50 "S" "SIP+D2T" ""
_sip._tcp.oversip.net.
oversip.net has NAPTR record 20 50 "S" "SIP+D2U" ""
_sip._udp.oversip.net.
oversip.net has NAPTR record 40 50 "S" "SIP+D2S" ""
_sip._sctp.oversip.net.
oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" ""
_sips._sctp.oversip.net.
So it should try TLS over TCP first, if it fails try TCP and if it
fails try UDP.
However it just uses UDP, why??
Even if I set a minor value to dns_tls_preference (so higher priority
I expect) it still uses UDP.
Am I doing something wrong? Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9 Jun
9 Jun
1:51 p.m.
2011/6/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
According to NAPTR:
~$ host -t naptr oversip.net
oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" ""
_sips._tcp.oversip.net.
oversip.net has NAPTR record 10 50 "S" "SIP+D2T" ""
_sip._tcp.oversip.net.
oversip.net has NAPTR record 20 50 "S" "SIP+D2U" ""
_sip._udp.oversip.net.
oversip.net has NAPTR record 40 50 "S" "SIP+D2S" ""
_sip._sctp.oversip.net.
oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" ""
_sips._sctp.oversip.net.
So it should try TLS over TCP first, if it fails try TCP and if it
fails try UDP.
Just to confirm, the above NAPTR record for "SIPS+D2T" has order 5 and
preference 50. According to 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
Preference
A 16-bit unsigned integer that specifies the order in which NAPTR
records with equal "order" values SHOULD be processed, low
numbers being processed before high numbers.
So as my domain oversip.net has no entries with same order, preference
value doesn't matter. And of course, SIP over TLS should take
preference.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:54 p.m.
2011/6/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
So as my domain oversip.net has no entries with same
order, preference
value doesn't matter. And of course, SIP over TLS should take
preference.
Also my SRV records are ok (using other SIP clients they choose TLS first):
$ host -t srv _sips._tcp.oversip.net.
_sips._tcp.oversip.net has SRV record 1 80 9091 sip1.oversip.net.
$ host -t a sip1.oversip.net.
sip1.oversip.net has address 91.121.79.216
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:08 p.m.
2011/6/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
According to NAPTR:
~$ host -t naptr oversip.net
oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" ""
_sips._tcp.oversip.net.
oversip.net has NAPTR record 10 50 "S" "SIP+D2T" ""
_sip._tcp.oversip.net.
oversip.net has NAPTR record 20 50 "S" "SIP+D2U" ""
_sip._udp.oversip.net.
oversip.net has NAPTR record 40 50 "S" "SIP+D2S" ""
_sip._sctp.oversip.net.
oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" ""
_sips._sctp.oversip.net.
So it should try TLS over TCP first, if it fails try TCP and if it
fails try UDP.
However it just uses UDP, why??
This is the Kamailio's log about DNS resolution for the above request
(note that I've restarted kamailio before the request in order to
clean any possible DNS cache):
DEBUG: <core> [dns_cache.c:567]: dns_hash_find(oversip.net(11), 35), h=956
DEBUG: <core> [resolve.c:924]: get_record: skipping 0 NS (p=0x826fdd,
end=0x826fdd)
DEBUG: <core> [resolve.c:940]: get_record: parsing 0 ARs (p=0x826fdd,
end=0x826fdd)
DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7f359f68db50
(oversip.net, 35), 35, *(nil)) (0)
DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding oversip.net(11)
35 (flags=0) at 956
DEBUG: <core> [dns_cache.c:567]:
dns_hash_find(_sip._udp.oversip.net(21), 33), h=23
DEBUG: <core> [resolve.c:924]: get_record: skipping 0 NS (p=0x826f0a,
end=0x826f0a)
DEBUG: <core> [resolve.c:940]: get_record: parsing 0 ARs (p=0x826f0a,
end=0x826f0a)
DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7f359f68de08
(_sip._udp.oversip.net, 33), 33, *(nil)) (0)
DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding
_sip._udp.oversip.net(21) 33 (flags=0) at 23
DEBUG: <core> [dns_cache.c:2362]: dns_srv_get_nxt_rr(0x7f359f68de08,
0, 0, 1367445037): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f359f68de60
p=0 w=0 rsum=0)
DEBUG: <core> [dns_cache.c:567]: dns_hash_find(sip.oversip.net(15), 1), h=400
DEBUG: <core> [resolve.c:924]: get_record: skipping 0 NS (p=0x826ef1,
end=0x826ef1)
DEBUG: <core> [resolve.c:940]: get_record: parsing 0 ARs (p=0x826ef1,
end=0x826ef1)
DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7f359f68def0
(sip.oversip.net, 1), 1, *(nil)) (0)
DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding
sip.oversip.net(15) 1 (flags=0) at 400
DEBUG: <core> [dns_cache.c:2982]: dns_a_resovle(sip.oversip.net, 0) returning 0
DEBUG: <core> [dns_cache.c:3236]:
dns_srv_resolve_ip("_sip._udp.oversip.net", 0, 0), ret=0,
ip=91.121.79.216
DEBUG: <core> [dns_cache.c:3358]: dns_sip_resolve(oversip.net, 0, 0),
srv0, ret=0
As per these logs I understand that no NAPTR record is taking place,
but just SRV for _sip._udp.oversip.net.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:13 p.m.
2011/6/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Even if I set a minor value to dns_tls_preference (so
higher priority
I expect) it still uses UDP.
By reading the doc it seems that higher values of dns_xxx_preference
take preference (it's the opposite to NAPTR records "order"). However
as I said I'm trying setting the same value for all the transports.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:26 p.m.
Hi Inaki,
I kind of lost the conclusion on your replies, is it not working as
documented/expected, or still not?
Cheers,
Daniel
On 6/9/11 2:13 PM, Iñaki Baz Castillo wrote:
2011/6/9 Iñaki Baz Castillo<ibc(a)aliax.net>et>:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
Even if I set a minor value to dns_tls_preference
(so higher priority
I expect) it still uses UDP.
By reading the doc it seems that higher values of
dns_xxx_preference
take preference (it's the opposite to NAPTR records "order"). However
as I said I'm trying setting the same value for all the transports.
5:11 p.m.
2011/6/9 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
I kind of lost the conclusion on your replies, is it
not working as
documented/expected, or still not?
Sorry for so many mails. No, it doesn't work as documented or
expected. Summarizing:
My Kamailio is not performing NAPTR query for a Request URI
"sip:xxxx@oversip.net" (no transport, no port). It just does SRV query
for SIP over UDP.
Kamailio info:
--------------------
version: kamailio 3.2.0-dev5 (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 04:43:00 Jun 9 2011 with gcc 4.4.3
-------------------
A MESSAGE with RURI "sip:qwe@oversip.net" arrives (no transport param,
no port), t_relay() is invoked, and kamailio just performs a SRV query
for SIP over UDP (as logs show):
-----------------------
DEBUG: <core> [dns_cache.c:567]: dns_hash_find(oversip.net(11), 35), h=956
DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7f98eebec390
(oversip.net, 35), 35, *(nil)) (0)
DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding oversip.net(11)
35 (flags=0) at 956
DEBUG: <core> [dns_cache.c:567]:
dns_hash_find(_sip._udp.oversip.net(21), 33), h=23
DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7f98eebec648
(_sip._udp.oversip.net, 33), 33, *(nil)) (0)
DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding
_sip._udp.oversip.net(21) 33 (flags=0) at 23
DEBUG: <core> [dns_cache.c:2362]: dns_srv_get_nxt_rr(0x7f98eebec648,
0, 0, 1616155624): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f98eebec6a0
p=0 w=0 rsum=0)
DEBUG: <core> [dns_cache.c:567]: dns_hash_find(sip.oversip.net(15), 1), h=400
DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7f98eebec730
(sip.oversip.net, 1), 1, *(nil)) (0)
DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding
sip.oversip.net(15) 1 (flags=0) at 400
DEBUG: <core> [dns_cache.c:2982]: dns_a_resovle(sip.oversip.net, 0) returning 0
DEBUG: <core> [dns_cache.c:3236]:
dns_srv_resolve_ip("_sip._udp.oversip.net", 0, 0), ret=0,
ip=91.121.79.216
DEBUG: <core> [dns_cache.c:3358]: dns_sip_resolve(oversip.net, 0, 0),
srv0, ret=0
------------------------
My DNS related configuration in Kamailio:
-----------------------
dns_try_ipv6=no
dns_retr_time=1
dns_retr_no=2
dns_servers_no=2
dns_srv_lb=yes
dns_try_naptr=yes
dns_use_search_list=no
dns_search_full_match=no
use_dns_cache=yes
dns_cache_init=yes
use_dns_failover=yes
dns_tls_preference=1
dns_tcp_preference=1
dns_udp_preference=1
-----------------------
According to the doc it should perform NAPTR query (it's compiled with
USE_NAPTR as "kamailio -V" says, and parameter dns_try_naptr has value
"yes").
Could somebody try to send a MESSAGE or INVITE through Kamailio 3.X
with RURI sip:whatever@oversip.net? According to NAPTR/SRV records,
destinations should be (in order of preference):
1) TLS 91.121.79.216:9091
2) TCP 91.121.79.216:9090
3) UDP 91.121.79.216:9090
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
8:34 p.m.
2011/6/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
According to the doc it should perform NAPTR query
(it's compiled with
USE_NAPTR as "kamailio -V" says, and parameter dns_try_naptr has value
"yes").
Could somebody try to send a MESSAGE or INVITE through Kamailio 3.X
with RURI sip:whatever@oversip.net? According to NAPTR/SRV records,
destinations should be (in order of preference):
1) TLS 91.121.79.216:9091
2) TCP 91.121.79.216:9090
3) UDP 91.121.79.216:9090
I've tested in other Kamailio 3.X boxes, with same configuration for
DNS and support for UDP and TCP. In all cases the same, Kamailio is
*NOT* performing a NAPTR query.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:26 p.m.
On Thursday 09 June 2011 12:44:11 Iñaki Baz Castillo wrote:
According to NAPTR:
~$ host -t naptr oversip.net
oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" ""
_sips._tcp.oversip.net. oversip.net has NAPTR record 10 50 "S"
"SIP+D2T"
"" _sip._tcp.oversip.net. oversip.net has NAPTR record 20 50 "S"
"SIP+D2U"
"" _sip._udp.oversip.net. oversip.net has NAPTR record 40 50 "S"
"SIP+D2S"
"" _sip._sctp.oversip.net. oversip.net has NAPTR record 50 50 "S"
"SIPS+D2S" "" _sips._sctp.oversip.net.
So it should try TLS over TCP first, if it fails try TCP and if it
fails try UDP.
However it just uses UDP, why??
Even if I set a minor value to dns_tls_preference (so higher priority
I expect) it still uses UDP.
The way I read rfc2915, there is no failover mechanism. The application pick
the first target that it supports and uses that. There is no mention of trying
other records afterwards. Matching/finding NAPTR records stops once the first
match is completed. All other records are discarded. From section 2:
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).
Note the last sentence.
--
Alex Hermann
8:03 p.m.
2011/6/9 Alex Hermann <alex(a)speakup.nl>nl>:
The way I read rfc2915, there is no failover
mechanism. The application pick
the first target that it supports and uses that. There is no mention of trying
other records afterwards. Matching/finding NAPTR records stops once the first
match is completed. All other records are discarded. From section 2:
Hi Alex, two comments:
1) What you say does not explain my issue (as in any case TLS or TCP
have more priority in my NAPTR's than UDP). In fact, my exact problem
is that my Kamailio is not performing NAPTR query.
2) About your quoted text, indeed RFC 2915 says that. But that just
means that, an application (in this case a SIP client) must take
*first* the valid NAPTR record with better "order" (lowest value). But
RFC 2915 is just about NAPTR, it can not mandate that applications or
protocols cannot try other NAPTR records as failover mechanism. Any
SIP client or proxy implementing NAPTR records does failover to the
next NAPTR record in case the first one failed (at least those I've
tested).
But anyhow, my main problem is that my Kamailio is not performing NAPTR query :)
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
15 Jun
15 Jun
3:32 p.m.
2011/6/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2011/6/9 Alex Hermann <alex(a)speakup.nl>nl>:
The problem is fixed now, it was an error related to the NAPTR service
flag (sip-router expected it to be "s" case-sensitive, while it should
also allow "S").
The way I read rfc2915, there is no failover
mechanism. The application pick
the first target that it supports and uses that. There is no mention of trying
other records afterwards. Matching/finding NAPTR records stops once the first
match is completed. All other records are discarded. From section 2:
Hi Alex, two comments:
1) What you say does not explain my issue (as in any case TLS or TCP
have more priority in my NAPTR's than UDP). In fact, my exact problem
is that my Kamailio is not performing NAPTR query. 2) About your quoted text, indeed RFC 2915 says that.
But that just
means that, an application (in this case a SIP client) must take
*first* the valid NAPTR record with better "order" (lowest value). But
RFC 2915 is just about NAPTR, it can not mandate that applications or
protocols cannot try other NAPTR records as failover mechanism. Any
SIP client or proxy implementing NAPTR records does failover to the
next NAPTR record in case the first one failed (at least those I've
tested).
It seems that sip-router behaves exactly as you describe. This it, it
performs the NAPTR resolution, chooses the record with best 'order'
(for the supported transports) and just uses it (it would do SRV
failover and so, but would never try other NAPTR records with less
'order').
However I've seen other SIP stacks also performing failover by taking
next NAPTR records. But indeed, RFC 2915 does not mandate it, instead
it says MUST NOT. So you are right.
Regards.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:09 p.m.
On Wednesday 15 June 2011, Iñaki Baz Castillo wrote:
2011/6/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
I forgot about a discussion i had about this issue a few years ago with a
customer and just remembered the outcome now. (Optional) failover can be
provided by different 'Preference' field within the same 'Order'. From rfc
2915/3403 section 2:
The important difference between Order and Preference is that
once a match is found the client MUST NOT consider records with a
different Order but they MAY process records with the same Order
but different Preferences. I.e., Preference is used to give weight
to rules that are considered the same from an authority
standpoint but not from a simple load balancing standpoint.
Unfortunately this wasn't possible with Kamailio <=1.5. Have you tried 3.x
with equal 'Order' but different 'Preference' or just with different
'Order'?
--
Greetings,
Alex Hermann
2011/6/9 Alex Hermann <alex(a)speakup.nl>nl>:
2) About your quoted text, indeed RFC 2915 says that. But that just
means that, an application (in this case a SIP client) must take
*first* the valid NAPTR record with better "order" (lowest value). But
RFC 2915 is just about NAPTR, it can not mandate that applications or
protocols cannot try other NAPTR records as failover mechanism. Any
SIP client or proxy implementing NAPTR records does failover to the
next NAPTR record in case the first one failed (at least those I've
tested).
It seems that sip-router behaves exactly as you describe. This it, it
performs the NAPTR resolution, chooses the record with best 'order'
(for the supported transports) and just uses it (it would do SRV
failover and so, but would never try other NAPTR records with less
'order').
However I've seen other SIP stacks also performing failover by taking
next NAPTR records. But indeed, RFC 2915 does not mandate it, instead
it says MUST NOT. So you are right.
4:26 p.m.
2011/6/15 Alex Hermann <alex(a)speakup.nl>nl>:
Yes, 100% right.
However
I've seen other SIP stacks also performing failover by taking
next NAPTR records. But indeed, RFC 2915 does not mandate it, instead
it says MUST NOT. So you are right.
I forgot about a discussion i had about this issue a few years ago with a
customer and just remembered the outcome now. (Optional) failover can be
provided by different 'Preference' field within the same 'Order'. From
rfc
2915/3403 section 2:
The important difference between Order and Preference is that
once a match is found the client MUST NOT consider records with a
different Order but they MAY process records with the same Order
but different Preferences. I.e., Preference is used to give weight
to rules that are considered the same from an authority
standpoint but not from a simple load balancing standpoint. Unfortunately this wasn't possible with Kamailio
<=1.5. Have you tried 3.x
with equal 'Order' but different 'Preference' or just with different
'Order'?
Not yet, but I'll do it and comment here :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:18 p.m.
2011/6/15 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Kamailio just takes one of the NAPTR records, even if the first fails
and there are more NAPTR records with same order (tested right now).
The file doc/dns-txt confirms it:
dns_try_naptr = on | off - if on sip-router will first try a NAPTR lookup for
destinations that don't have the protocol or port specified and
are not simple ip addresses (as described in RFC 3263). This will
introduce a slight performance penalty and will probably cause extra
DNS lookups. For example a lookup for a non-existing domain will
produce one extra query: NAPTR(domain), SRV(_sip._udp.domain)
and A/AAAA(domain).
If the result of a query contains several NAPTR records,
sip-router will select
among them according to the RFC2915 and sip-router preference towards a
specific protocol (see dns_udp_pref, dns_tcp_pref and dns_tls_pref
below). For an RFC3263 compliant configuration (choose the remote side
preferred protocol if supported), set dns_udp_pref, dns_tcp_pref and
dns_tls_pref to the same value (>=0), e.g. 0.
Default: off
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Unfortunately
this wasn't possible with Kamailio <=1.5. Have you tried 3.x
with equal 'Order' but different 'Preference' or just with different
'Order'?
Not yet, but I'll do it and comment here :) 
10 Jun
10 Jun
3:05 p.m.
My Kamailio 3.1.3 performs NATPR lookups:
use_dns_cache = yes
dns_try_naptr = yes
dns_udp_pref=1
dns_tcp_pref=1
dns_tls_pref=1
dns_sctp_pref=1
dns_use_search_list=no
dns_try_ipv6=yes
dns_retr_time=1
dns_retr_no=1
regards
Klaus
Am 09.06.2011 12:44, schrieb Iñaki Baz Castillo:
Hi, I'm testing Kamailio's NAPTR resolution:
version: kamailio 3.2.0-dev4 (x86_64/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS,
USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM,
SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX,
FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB
DNS related configuration:
dns_servers_no=2
dns_srv_lb=yes
dns_try_naptr=yes
dns_use_search_list=no
use_dns_cache=yes
use_dns_failover=yes
dns_tls_preference=1
dns_tcp_preference=1
dns_udp_preference=1
As the doc says it should respect the priorities of the NAPTR records,
see
http://kamailio.org/dokuwiki/doku.php/core-cookbook:3.1.x#dns_sctp_pref_dns…:
"To use the remote site preferences set all dns_*_pref to the same
positive value
(e.g. dns_udp_pref=1, dns_tcp_pref=1, dns_tls_pref=1, dns_sctp_pref=1)"
So my kamailio receives an INVITE for an external domain oversip.net
(no transport param neither port in the RURI) and does a t_relay.
Request RURI is sip:qwe@oversip.net.
According to NAPTR:
~$ host -t naptr oversip.net
oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" ""
_sips._tcp.oversip.net.
oversip.net has NAPTR record 10 50 "S" "SIP+D2T" ""
_sip._tcp.oversip.net.
oversip.net has NAPTR record 20 50 "S" "SIP+D2U" ""
_sip._udp.oversip.net.
oversip.net has NAPTR record 40 50 "S" "SIP+D2S" ""
_sip._sctp.oversip.net.
oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" ""
_sips._sctp.oversip.net.
So it should try TLS over TCP first, if it fails try TCP and if it
fails try UDP.
However it just uses UDP, why??
Even if I set a minor value to dns_tls_preference (so higher priority
I expect) it still uses UDP.
Am I doing something wrong? Thanks a lot.
3:23 p.m.
2011/6/10 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
My Kamailio 3.1.3 performs NATPR lookups:
use_dns_cache = yes
dns_try_naptr = yes
dns_udp_pref=1
dns_tcp_pref=1
dns_tls_pref=1
dns_sctp_pref=1
dns_use_search_list=no
dns_try_ipv6=yes
dns_retr_time=1
dns_retr_no=1
With your exact configuration, my kamailio 3.2.0-dev5 (debian package)
does not perform NAPTR :(
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
3:30 p.m.
2011/6/10 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
With your exact configuration, my kamailio 3.2.0-dev5
(debian package)
does not perform NAPTR :(
Klaus, could you provide me the following information?
1) kamailio -V
2) Is compiled? a deb package?
3) Could you please call sip:anything@oversip.net and show me kamailio
logs by filtering "dns" ( grep | dns ) ?
Really thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:14 p.m.
Kamailio performs NAPTR lookups, but chooses UDP. I do not know why.
# kamailio -V
version: kamailio 3.1.3 (i386/linux)
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
USE_STUN, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT,
USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST,
HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535, PKG_SIZE 4MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown
compiled on 14:01:24 May 13 2011 with gcc 4.3.2
# tail -f /var/log/kamailio|grep dns
<core> [dns_cache.c:567]: dns_hash_find(oversip.net(11), 35), h=956
<core> [dns_cache.c:1777]: dns_get_related(0xb3921838 (oversip.net, 35),
35, *0x8366a5c) (0)
<core> [dns_cache.c:870]: dns_cache_add: adding oversip.net(11) 35
(flags=0) at 956
<core> [dns_cache.c:567]: dns_hash_find(_sip._udp.oversip.net(21), 33), h=23
<core> [dns_cache.c:1777]: dns_get_related(0xb3921a08
(_sip._udp.oversip.net, 33), 33, *0x8366a5c) (0)
<core> [dns_cache.c:870]: dns_cache_add: adding
_sip._udp.oversip.net(21) 33 (flags=0) at 23
<core> [dns_cache.c:870]: dns_cache_add: adding sip.oversip.net(15) 1
(flags=0) at 400
<core> [dns_cache.c:567]: dns_hash_find(sip.oversip.net(15), 1), h=400
# tshark host 83.136.32.159 or port 53
A -> B TCP 4923 > sip [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=3
B -> A TCP sip > 4923 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
A -> B TCP 4923 > sip [ACK] Seq=1 Ack=1 Win=415024 Len=0
A -> B SIP/SDP Request: INVITE sip:anything@oversip.net, with session
description
B -> A TCP sip > 4923 [ACK] Seq=1 Ack=867 Win=8768 Len=0
B -> A SIP Status: 407 Proxy Authentication Required
A -> B SIP Request: ACK sip:anything@oversip.net
B -> A TCP sip > 4923 [ACK] Seq=676 Ack=1239 Win=10496 Len=0
A -> B SIP/SDP Request: INVITE sip:anything@oversip.net, with session
description
B -> A TCP sip > 4923 [ACK] Seq=676 Ack=2310 Win=13440 Len=0
B -> A SIP Status: 100 your wish is my command,
ru=sip:anything@oversip.net, du=<null>
C -> D DNS Standard query NAPTR oversip.net
D -> C DNS Standard query response NAPTR 20 50 S NAPTR 40 50 S NAPTR 50
50 S NAPTR 5 50 S NAPTR 10 50 S
C -> D DNS Standard query SRV _sip._udp.oversip.net
D -> C DNS Standard query response SRV 0 0 9090 sip.oversip.net
B -> D SIP/SDP Request: INVITE sip:anything@oversip.net, with session
description
D -> B SIP Status: 555 Ok, I'm here, your request arrives via UDP
B -> D SIP Request: ACK sip:anything@oversip.net
B -> A SIP Status: 555 Ok, I'm here, your request arrives via UDP
A -> B TCP 4923 > sip [ACK] Seq=2310 Ack=1682 Win=415024 Len=0
A -> B SIP Request: ACK sip:anything@oversip.net
B -> A TCP sip > 4923 [ACK] Seq=1682 Ack=2662 Win=15616 Len=0
Am 10.06.2011 14:30, schrieb Iñaki Baz Castillo:
2011/6/10 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
With your exact configuration, my kamailio
3.2.0-dev5 (debian package)
does not perform NAPTR :(
Klaus, could you provide me the following information?
1) kamailio -V
2) Is compiled? a deb package?
3) Could you please call sip:anything@oversip.net and show me kamailio
logs by filtering "dns" ( grep | dns ) ?
Really thanks a lot.
4:33 p.m.
2011/6/10 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Kamailio performs NAPTR lookups, but chooses UDP. I do
not know why.
You are fully right. I've captured DNS traffic and wireshark clearly
shows a NAPTR record. And indeed kamailio prefers SIP over UDP with no
reason (it should prefer TCP as my kamailio does not speak TLS):
$ host -t naptr oversip.net
oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" ""
_sips._tcp.oversip.net.
oversip.net has NAPTR record 10 50 "S" "SIP+D2T" ""
_sip._tcp.oversip.net.
oversip.net has NAPTR record 20 50 "S" "SIP+D2U" ""
_sip._udp.oversip.net.
oversip.net has NAPTR record 40 50 "S" "SIP+D2S" ""
_sip._sctp.oversip.net.
oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" ""
_sips._sctp.oversip.net.
Maybe kamailio is taking the "order" field of the NAPTR incorrectly
and gives priority with higher values? I will check it ASAP.
Thanks a lot Klaus.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9:23 p.m.
2011/6/10 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
Maybe kamailio is taking the "order" field
of the NAPTR incorrectly
and gives priority with higher values? I will check it ASAP.
Ok, I've created domain whose NAPTR record just includes a single
SIP+D2T entry (just SIP over TCP).
My Kamailio (which uses UDP and TCP) indeed performs the NAPTR
queries, but it seems it doesn't like the response and ignores it.
Then it performs an usual _sip._udp SRP query.
My DNS domains and NAPTR/SRV/A records work OK with any other SIP
client implementing RFC 3263.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:06 p.m.
On 6/10/11 8:23 PM, Iñaki Baz Castillo wrote:
2011/6/10 Iñaki Baz Castillo<ibc(a)aliax.net>et>:
Could you set children to 1, attach with gdb to the sip worker handling
the invite, send the call and execute step by step to see which
condition fails? A simple config with t_relay() should make the
debugging easier.
Thanks,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Maybe kamailio is taking the "order"
field of the NAPTR incorrectly
and gives priority with higher values? I will check it ASAP.
Ok, I've created
domain whose NAPTR record just includes a single
SIP+D2T entry (just SIP over TCP).
My Kamailio (which uses UDP and TCP) indeed performs the NAPTR
queries, but it seems it doesn't like the response and ignores it.
Then it performs an usual _sip._udp SRP query.
My DNS domains and NAPTR/SRV/A records work OK with any other SIP
client implementing RFC 3263.
11 Jun
11 Jun
12:16 a.m.
2011/6/10 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Could you set children to 1, attach with gdb to the
sip worker handling the
invite, send the call and execute step by step to see which condition fails?
A simple config with t_relay() should make the debugging easier.
Hi Daniel. Which worker should I attach? My kamailio listens in UDP
and TCP. I send the request via UDP and it should do NAPTR stuf and
choose SIP TCP (best priority). So:
Process:: ID=0 PID=26913 Type=attendant
Process:: ID=1 PID=26914 Type=udp receiver child=0 sock=192.168.1.16:8080
Process:: ID=2 PID=26915 Type=slow timer
Process:: ID=3 PID=26916 Type=timer
Process:: ID=4 PID=26917 Type=MI FIFO
Process:: ID=5 PID=26918 Type=ctl handler
Process:: ID=6 PID=26919 Type=tcp receiver child=0
Process:: ID=7 PID=26920 Type=tcp main process
Which process should I attach? udp receiver?
I've tryed to attach udp receiver process in gdb, and by pressing
"next", "next", "next" (running gdb in the kamailio sources
directory)
I see nothing about dns functions. Could you please give me some
indications please?
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:23 a.m.
Hello,
On 6/10/11 11:16 PM, Iñaki Baz Castillo wrote:
2011/6/10 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
yes, attach to the process that receives the sip request, in
this case
the udp receiver.
Then if you use a simple config with t_relay(), go to tm module, see
where t_relay() is defined, follow a bit the code and set a breakpoint
by file and line number at a convenient location (as much as close to
dns lookup functions if you can spot them in the code), so you don't do
next/next/ too many times.
Cheers.
Daniel
Could you set children to 1, attach with gdb to
the sip worker handling the
invite, send the call and execute step by step to see which condition fails?
A simple config with t_relay() should make the debugging easier.
Hi Daniel. Which
worker should I attach? My kamailio listens in UDP
and TCP. I send the request via UDP and it should do NAPTR stuf and
choose SIP TCP (best priority). So:
Process:: ID=0 PID=26913 Type=attendant
Process:: ID=1 PID=26914 Type=udp receiver child=0 sock=192.168.1.16:8080
Process:: ID=2 PID=26915 Type=slow timer
Process:: ID=3 PID=26916 Type=timer
Process:: ID=4 PID=26917 Type=MI FIFO
Process:: ID=5 PID=26918 Type=ctl handler
Process:: ID=6 PID=26919 Type=tcp receiver child=0
Process:: ID=7 PID=26920 Type=tcp main process
Which process should I attach? udp receiver?
I've tryed to attach udp receiver process in gdb, and by pressing
"next", "next", "next" (running gdb in the kamailio sources
directory)
I see nothing about dns functions. Could you please give me some
indications please?
12:26 a.m.
2011/6/10 Daniel-Constantin Mierla <daniel(a)kamailio.org>rg>:
yes, attach to the process that receives the sip
request, in this case the
udp receiver.
Then if you use a simple config with t_relay(), go to tm module, see where
t_relay() is defined, follow a bit the code and set a breakpoint by file and
line number at a convenient location (as much as close to dns lookup
functions if you can spot them in the code), so you don't do next/next/ too
many times.
Understood. Let me some time to do it and I'll come back. Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:24 a.m.
2011/6/10 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
> Then if you use a simple config with t_relay(), go
to tm module, see where
> t_relay() is defined, follow a bit the code and set a breakpoint by file and
> line number at a convenient location (as much as close to dns lookup
> functions if you can spot them in the code), so you don't do next/next/ too
> many times.
Hi Daniel, I tryed to extract some useful data but got nothing. I've
set breakpoints by indicating file:line of tm module as well as
resolve.c file. The same using function names as breakpoints, etc. No
result at all, I just get stuf about "UDP, IO, read" and so.
Anyhow I've make some other tests and concluded that the issue is very
simple: Kamailio performs NAPTR query but completely ignores its
result. I've reported the bug in the tracker:
http://sip-router.org/tracker/index.php?do=details&task_id=135
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
13 Jun
13 Jun
1:04 p.m.
Hello,
On 6/11/11 9:24 AM, Iñaki Baz Castillo wrote:
2011/6/10 Iñaki Baz Castillo<ibc(a)aliax.net>et>:
I saw Andrei
jumped in and added case insensitive comparison of naptr
flags -- just to conclude this discussion, is it working on now?
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
> Then if you use a simple config with
t_relay(), go to tm module, see where
> t_relay() is defined, follow a bit the code and set a breakpoint by file and
> line number at a convenient location (as much as close to dns lookup
> functions if you can spot them in the code), so you don't do next/next/ too
> many times.
Hi Daniel, I tryed to extract some useful data but got nothing.
I've
set breakpoints by indicating file:line of tm module as well as
resolve.c file. The same using function names as breakpoints, etc. No
result at all, I just get stuf about "UDP, IO, read" and so.
Anyhow I've make some other tests and concluded that the issue is very
simple: Kamailio performs NAPTR query but completely ignores its
result. I've reported the bug in the tracker:
http://sip-router.org/tracker/index.php?do=details&task_id=135
3:48 p.m.
2011/6/13 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
I saw Andrei jumped in and added case insensitive
comparison of naptr flags
-- just to conclude this discussion, is it working on now?
Hi Daniel, I've tested it right *now* :)
Yes, it works.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4:55 p.m.
On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2011/6/13 Daniel-Constantin Mierla
<miconda(a)gmail.com>om>:
Ok, thanks.
Cheers,
Daniel
I saw Andrei jumped in and added case insensitive
comparison of naptr flags
-- just to conclude this discussion, is it working on now?
Hi Daniel, I've tested it right *now* :)
Yes, it works.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
15 Jun
15 Jun
10:56 a.m.
One more question here, since I remembered about it -- have you played
with dns-based load balancing done by proxy so far? This was new for
kamailio in 3.x...
Thanks,
Daniel
On 6/13/11 3:55 PM, Daniel-Constantine Mierla wrote:
On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castillo<ibc(a)aliax.net> wrote:
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
2011/6/13 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
I saw Andrei jumped in and added case insensitive
comparison of naptr flags
-- just to conclude this discussion, is it working on now?
Hi Daniel, I've
tested it right *now* :)
Yes, it works.
11:11 a.m.
2011/6/15 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
One more question here, since I remembered about it --
have you played with
dns-based load balancing done by proxy so far? This was new for kamailio in
3.x...
I started playing a bit and got good results, but want to make further tests.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4912
days inactive
4918
days old
29 comments
6 participants
participants (6)
-
Alex Hermann -
Daniel-Constantin Mierla -
Daniel-Constantin Mierla -
Daniel-Constantine Mierla
-
Iñaki Baz Castillo -
Klaus Darilion