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:[email protected]" (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:[email protected]>
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:[email protected]]
DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body
[sip:[email protected]#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:[email protected]" 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.
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
