[sr-dev] [tracker] Task changed: NAPTR records are retrieved but fully ignored

Sat Jun 11 09:19:07 CEST 2011

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 at 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 at 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 at aliax.net]
    DEBUG: <core> [parser/msg_parser.c:189]: DEBUG: to body [sip:ibc at 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 at 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.