11 Jun
2011
11 Jun
'11
9:19 a.m.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has been changed. The changes are listed below. For full information
about what has changed, visit the URL and click the History tab.
FS#135 - NAPTR records are retrieved but fully ignored
User who did this: Iñaki Baz Castillo (ibc)
Task details edited:
-------
By doing several tests I'm pretty sure that kamailio 3.2.0-dev5 performs NAPTR query
but ignores its results.
Kamailio (deb package) has USE_NAPTR flag:
version: kamailio 3.2.0-dev5 (x86_64/linux) cb30d9
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: cb30d9
compiled on 23:08:36 Jun 10 2011 with gcc 4.5.2
Kamailio DNS related parateres (according to the doc they are correct in order to do
complete NAPTR/SRV stuf):
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
dns_sctp_preference=1
My Kamailio listens into UDP and TCP. The config file just does a t_relay(), no more.
Kamailio receives a request with RURI "sip:qweqwe@naptr-test2.oversip.net" (no
transport param, neither port). The existing DNS NAPTR records for such domain
"naptr-test2.oversip.net" are:
~# host -t naptr naptr-test2.oversip.net
naptr-test2.oversip.net has NAPTR record 10 50 "S" "SIP+D2U"
"" _sip._udp.lalala.oversip.net.
Please note that the domain in the 'replacement' field of the NAPTR record is not
"_sip._udp.naptr-test2.oversip.net", but
"_sip._udp.lalala.oversip.net" (perfectly valid according to RFC 3261).
Kamailio processes the request, performs a NAPTR query for domain
"naptr-test2.oversip.net", receives the DNS response, but makes no usage of it.
Instead it behaves as if no NAPTR record(s) exist and go to next DNS step by querying DNS
SRV "_sip._udp.naptr-test2.oversip.net" (which does not exist, neither there is
a DNS A record for it) so it fails and replies 478 'Unresolvable destination
(478/TM)'.
I attach a tcpdump capture (exported to TXT) of the DNS queries performed by Kamailio.
Kamailio logs say:
DEBUG: <core> [parser/msg_parser.c:630]: SIP Request:
DEBUG: <core> [parser/msg_parser.c:632]: method: <MESSAGE>
DEBUG: <core> [parser/msg_parser.c:634]: uri:
<sip:qweqwe@naptr-test2.oversip.net>
DEBUG: <core> [parser/msg_parser.c:636]: version: <SIP/2.0>
DEBUG: <core> [parser/parse_via.c:1287]: Found param type 232, <branch> =
<z9hG4bK1784ca8c0f4fc-1>; state=6
DEBUG: <core> [parser/parse_via.c:1287]: Found param type 235, <rport> =
<n/a>; state=6
DEBUG: <core> [parser/parse_via.c:1287]: Found param type 253, <kaka2> =
<n/a>; state=6
DEBUG: <core> [parser/parse_via.c:1287]: Found param type 253, <KAKA3> =
<%61lice>; state=9
DEBUG: <core> [parser/parse_via.c:2343]: parse_via: next_via
DEBUG: <core> [parser/parse_via.c:2300]: end of header reached, state=2
DEBUG: <core> [parser/msg_parser.c:515]: parse_headers: Via found, flags=2
DEBUG: <core> [parser/msg_parser.c:517]: parse_headers: this is the first via
DEBUG: <core> [receive.c:146]: After parse_msg...
DEBUG: <core> [receive.c:187]: preparing to run routing scripts...
DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=1 , global msg id=0 , T on
entrance=0xffffffffffffffff
DEBUG: <core> [parser/parse_to.c:803]: end of header reached, state=9
DEBUG: <core> [parser/msg_parser.c:187]: DEBUG: get_hdr_field: <T> [19];
uri=[sip:ibc@aliax.net]
DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body
[sip:ibc@aliax.net#015#012]
DEBUG: <core> [parser/msg_parser.c:167]: get_hdr_field: cseq <Cseq>:
<914577526> <MESSAGE>
DEBUG: <core> [parser/msg_parser.c:201]: DEBUG: get_hdr_body :
content_length=11
DEBUG: <core> [parser/msg_parser.c:103]: found end of header
DEBUG: tm [t_lookup.c:528]: t_lookup_request: start searching: hash=33819, isACK=0
DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
DEBUG: tm [t_lookup.c:711]: DEBUG: t_lookup_request: no transaction found
DEBUG: tm [t_hooks.c:374]: DBG: trans=0x7fe5add5f038, callback type 1, id 0 entered
DEBUG: <core> [dns_cache.c:567]: dns_hash_find(naptr-test2.oversip.net(23), 35),
h=1000
DEBUG: <core> [resolve.c:924]: get_record: skipping 0 NS (p=0x827f62,
end=0x827f62)
DEBUG: <core> [resolve.c:940]: get_record: parsing 0 ARs (p=0x827f62,
end=0x827f62)
DEBUG: <core> [dns_cache.c:1777]: dns_get_related(0x7fe5add61318
(naptr-test2.oversip.net, 35), 35, *(nil)) (0)
DEBUG: <core> [dns_cache.c:870]: dns_cache_add: adding
naptr-test2.oversip.net(23) 35 (flags=0) at 1000
DEBUG: <core> [dns_cache.c:567]:
dns_hash_find(_sip._udp.naptr-test2.oversip.net(33), 33), h=565
DEBUG: <core> [resolve.c:727]: get_record:
lookup(_sip._udp.naptr-test2.oversip.net, 33) failed
DEBUG: <core> [dns_cache.c:895]:
dns_cache_mk_bad_entry(_sip._udp.naptr-test2.oversip.net, 33, 60, 1)
DEBUG: <core> [dns_cache.c:828]: dns_cache_add: adding
_sip._udp.naptr-test2.oversip.net(33) 33 (flags=1) at 565
DEBUG: <core> [dns_cache.c:3236]:
dns_srv_resolve_ip("_sip._udp.naptr-test2.oversip.net", 0, 0), ret=-5, ip=
DEBUG: <core> [dns_cache.c:567]: dns_hash_find(naptr-test2.oversip.net(23), 1),
h=1000
DEBUG: <core> [resolve.c:727]: get_record: lookup(naptr-test2.oversip.net, 1)
failed
The same can be demostrated by sending a request with RURI
"sip:1234@oversip.net" to Kamailio. NAPTR records for "oversip.net"
domain are:
~# host -t naptr 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.
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.
As you can see, the preferred order is TLS, TCP and UDP (ignoring SCTP). Kamailio performs
the NAPTR query, but then always queries DNS SRV _sip._udp.oversip.net. Note that, as
demostrated above, I don't think it does it because it chooses UDP from the list of
NAPTR records, but because it just fully ignores NAPTR records (if it wasn't ignore
NAPTR records but always chose UDP, then in the above case it would query "DNS SRV
_sip._udp.lalala.oversip.net" rather than "DNS SRV
_sip._udp.naptr-test2.oversip.net").
-------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=135
You are receiving this message because you have requested it from the Flyspray bugtracking
system. If you did not expect this message or don't want to receive mails in future,
you can change your notification settings at the URL shown above.