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.