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 Castilloibc@aliax.net:

...

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.

2011/6/9 Iñaki Baz Castillo ibc@aliax.net:

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.

2011/6/9 Alex Hermann alex@speakup.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.

On Wednesday 15 June 2011, Iñaki Baz Castillo wrote:

2011/6/9 Iñaki Baz Castillo ibc@aliax.net:

...

2011/6/9 Alex Hermann alex@speakup.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.

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'?

2011/6/15 Iñaki Baz Castillo ibc@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 :)

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

2011/6/10 Klaus Darilion klaus.mailinglists@pernau.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 :(

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@aliax.net:

...

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.

2011/6/10 Iñaki Baz Castillo ibc@aliax.net:

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.

2011/6/10 Daniel-Constantin Mierla miconda@gmail.com:

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.

2011/6/10 Daniel-Constantin Mierla daniel@kamailio.org:

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.

Hello,

On 6/11/11 9:24 AM, Iñaki Baz Castillo wrote:

2011/6/10 Iñaki Baz Castilloibc@aliax.net:

...

...

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

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

On Jun 13, 2011, at 2:48 PM, Iñaki Baz Castillo ibc@aliax.net wrote:

2011/6/13 Daniel-Constantin Mierla miconda@gmail.com:

...

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.

Ok, thanks.

Cheers, Daniel

-- Iñaki Baz Castillo ibc@aliax.net

2011/6/15 Daniel-Constantin Mierla miconda@gmail.com:

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.