Hi,
I'm having problems connecting to a videoservice at seevia.no, because they have no NAPTR nor _sip._udp.seevia.no entry. They do have for tcp and sips:
% host -t NAPTR seevia.no seevia.no has no NAPTR record % host -t SRV _sip._udp.seevia.no Host _sip._udp.seevia.no not found: 3(NXDOMAIN) % host -t SRV _sip._tcp.seevia.no _sip._tcp.seevia.no has SRV record 1 0 5060 vcse.vcn.no. % host -t SRV _sips._tcp.seevia.no _sips._tcp.seevia.no has SRV record 1 0 5061 vcse.vcn.no. % host -t A vcse.vcn.no. vcse.vcn.no has address 85.19.200.18 vcse.vcn.no has address 62.92.46.211 % host -t A seevia.no seevia.no has address 93.89.34.42
Ref an old thread on sr-dev, http://lists.sip-router.org/pipermail/sr-dev/2012-October/016969.html this should have been fixed by http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=63ef5f0edcfebe86cffe7489f3524186ed3400d4.
From tcpdump:
65177+ NAPTR? seevia.no. (27) 65177 0/1/0 (86) 31896+ SRV? _sip._udp.seevia.no. (37) 31896 NXDomain 0/1/0 (96) 54304+ A? seevia.no. (27) 54304 1/2/2 A 42.93-89-34.enivest.net (119)
Trivial to see it does not attempt to lookup anything after a NXDOMAIN for _sip._udp.seevia.no.
% host -t A 42.93-89-34.enivest.net 42.93-89-34.enivest.net has address 93.89.34.42
Any idea why my INVITEs are being sent to 93.89.34.42 instead one of vcse.uio.no's IPs?
My dns settings:
use_dns_cache=on use_dns_failover=on dns_try_ipv6=no dns_retr_time=1 dns_retr_no=2 dns_use_search_list=no dns_try_naptr = yes dns_srv_lb = yes
I'm running latest 4.0: % kamailio -V version: kamailio 4.0.3 (i386/linux) a331af 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, 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: a331af compiled on 11:30:24 Sep 17 2013 with gcc 4.1.2
Hello,
can you make a test with debug=3 and send the logs to me?
Cheers, Daniel
On 9/17/13 1:13 PM, Øyvind Kolbu wrote:
Hi,
I'm having problems connecting to a videoservice at seevia.no, because they have no NAPTR nor _sip._udp.seevia.no entry. They do have for tcp and sips:
% host -t NAPTR seevia.no seevia.no has no NAPTR record % host -t SRV _sip._udp.seevia.no Host _sip._udp.seevia.no not found: 3(NXDOMAIN) % host -t SRV _sip._tcp.seevia.no _sip._tcp.seevia.no has SRV record 1 0 5060 vcse.vcn.no. % host -t SRV _sips._tcp.seevia.no _sips._tcp.seevia.no has SRV record 1 0 5061 vcse.vcn.no. % host -t A vcse.vcn.no. vcse.vcn.no has address 85.19.200.18 vcse.vcn.no has address 62.92.46.211 % host -t A seevia.no seevia.no has address 93.89.34.42
Ref an old thread on sr-dev, http://lists.sip-router.org/pipermail/sr-dev/2012-October/016969.html this should have been fixed by http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=63ef5f0edcfebe86cffe7489f3524186ed3400d4.
From tcpdump:
65177+ NAPTR? seevia.no. (27) 65177 0/1/0 (86) 31896+ SRV? _sip._udp.seevia.no. (37) 31896 NXDomain 0/1/0 (96) 54304+ A? seevia.no. (27) 54304 1/2/2 A 42.93-89-34.enivest.net (119)
Trivial to see it does not attempt to lookup anything after a NXDOMAIN for _sip._udp.seevia.no.
% host -t A 42.93-89-34.enivest.net 42.93-89-34.enivest.net has address 93.89.34.42
Any idea why my INVITEs are being sent to 93.89.34.42 instead one of vcse.uio.no's IPs?
My dns settings:
use_dns_cache=on use_dns_failover=on dns_try_ipv6=no dns_retr_time=1 dns_retr_no=2 dns_use_search_list=no dns_try_naptr = yes dns_srv_lb = yes
I'm running latest 4.0: % kamailio -V version: kamailio 4.0.3 (i386/linux) a331af 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, 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: a331af compiled on 11:30:24 Sep 17 2013 with gcc 4.1.2
Hello,
On 9/17/13 2:30 PM, Øyvind Kolbu wrote:
On 17.09.2013 14:08, Daniel-Constantin Mierla wrote:
Hello,
can you make a test with debug=3 and send the logs to me?
Sent, thanks!
from the logs, it seems it does A record on seevia.no:
DEBUG: <core> [dns_cache.c:3007]: dns_a_resolve(): dns_a_resolve(seevia.no, 0) returning 0
and later the transaction is forwarded:
DEBUG: tm [t_funcs.c:393]: t_relay_to(): SER: new transaction fwd'ed
Have looked at SIP traffic on the network?
Cheers, Daniel
On 17.09.2013 23:01, Daniel-Constantin Mierla wrote:
DEBUG: <core> [dns_cache.c:3007]: dns_a_resolve(): dns_a_resolve(seevia.no, 0) returning 0
Which it should not have done before trying to resolve at least _sip._tcp.seevia.no. I have not configured tls, not sure it will attempt to lookup _sips._tcp.seevia.no then.
and later the transaction is forwarded:
DEBUG: tm [t_funcs.c:393]: t_relay_to(): SER: new transaction fwd'ed
Have looked at SIP traffic on the network?
Yes, it sends to the A record:
U 2013/09/17 08:34:18.299250 129.240.253.196:7060 -> 93.89.34.42:5060 INVITE sip:redacted@seevia.no SIP/2.0.
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pref...
By default, the highest is to follow on UDP.
Cheers, Daniel
On 9/18/13 9:33 AM, Øyvind Kolbu wrote:
On 17.09.2013 23:01, Daniel-Constantin Mierla wrote:
DEBUG: <core> [dns_cache.c:3007]: dns_a_resolve(): dns_a_resolve(seevia.no, 0) returning 0
Which it should not have done before trying to resolve at least _sip._tcp.seevia.no. I have not configured tls, not sure it will attempt to lookup _sips._tcp.seevia.no then.
and later the transaction is forwarded:
DEBUG: tm [t_funcs.c:393]: t_relay_to(): SER: new transaction fwd'ed
Have looked at SIP traffic on the network?
Yes, it sends to the A record:
U 2013/09/17 08:34:18.299250 129.240.253.196:7060 -> 93.89.34.42:5060 INVITE sip:redacted@seevia.no SIP/2.0.
18 sep 2013 kl. 10:55 skrev Daniel-Constantin Mierla miconda@gmail.com:
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pref...
By default, the highest is to follow on UDP.
But that seems to be for NAPTR and the question was about having no NAPTR Or am I just confused?
/O
Cheers, Daniel
On 9/18/13 9:33 AM, Øyvind Kolbu wrote:
On 17.09.2013 23:01, Daniel-Constantin Mierla wrote:
DEBUG: <core> [dns_cache.c:3007]: dns_a_resolve(): dns_a_resolve(seevia.no, 0) returning 0
Which it should not have done before trying to resolve at least _sip._tcp.seevia.no. I have not configured tls, not sure it will attempt to lookup _sips._tcp.seevia.no then.
and later the transaction is forwarded:
DEBUG: tm [t_funcs.c:393]: t_relay_to(): SER: new transaction fwd'ed
Have looked at SIP traffic on the network?
Yes, it sends to the A record:
U 2013/09/17 08:34:18.299250 129.240.253.196:7060 -> 93.89.34.42:5060 INVITE sip:redacted@seevia.no SIP/2.0.
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013
- more details about Kamailio trainings at http://www.asipto.com -
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
On 18.09.2013 11:32, Olle E. Johansson wrote:
18 sep 2013 kl. 10:55 skrev Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>:
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pref...
By default, the highest is to follow on UDP.
But that seems to be for NAPTR and the question was about having no NAPTR Or am I just confused?
Correct, no NAPTR. Only SRV, but until yesterday, no _sip._udp and then it immediately tried an A lookup instead of attempting _sip._tcp. I have also tried to set those prefs, but it did not help.
On 9/18/13 12:04 PM, Øyvind Kolbu wrote:
On 18.09.2013 11:32, Olle E. Johansson wrote:
18 sep 2013 kl. 10:55 skrev Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com>:
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pref...
By default, the highest is to follow on UDP.
But that seems to be for NAPTR and the question was about having no NAPTR Or am I just confused?
Correct, no NAPTR. Only SRV, but until yesterday, no _sip._udp and then it immediately tried an A lookup instead of attempting _sip._tcp. I have also tried to set those prefs, but it did not help.
I got confused by the tcp dump and missed first remark, I thought udp srv query returned two hosts for A lookup, first failing and second not tried. I will look again over it.
Cheers, Daniel
On 18.09.2013 12:17, Daniel-Constantin Mierla wrote:
On 9/18/13 12:04 PM, Øyvind Kolbu wrote:
Correct, no NAPTR. Only SRV, but until yesterday, no _sip._udp and then it immediately tried an A lookup instead of attempting _sip._tcp. I have also tried to set those prefs, but it did not help.
I got confused by the tcp dump and missed first remark, I thought udp srv query returned two hosts for A lookup, first failing and second not tried. I will look again over it.
Hi,
any ideas?
On 9/24/13 11:23 AM, Øyvind Kolbu wrote:
On 18.09.2013 12:17, Daniel-Constantin Mierla wrote:
On 9/18/13 12:04 PM, Øyvind Kolbu wrote:
Correct, no NAPTR. Only SRV, but until yesterday, no _sip._udp and then it immediately tried an A lookup instead of attempting _sip._tcp. I have also tried to set those prefs, but it did not help.
I got confused by the tcp dump and missed first remark, I thought udp srv query returned two hosts for A lookup, first failing and second not tried. I will look again over it.
Hi,
any ideas?
Haven't got time to get back to it -- hope to happen soon.
Cheers, Daniel
On 2013-09-27 at 11:49, Daniel-Constantin Mierla wrote:
Haven't got time to get back to it -- hope to happen soon.
I've taken a small peak and think I at least found some of the problem, but also got quite confused.
What is the relationship between dns_cache.c:dns_srv_sip_resolvehost() and dns_cache.c:dns_srv_sip_resolve()? They look very much copy and paste, with the same error in them. Both will only search for UDP records if *proto is not set. They also mangle the *proto value as they both set it to PROTO_UDP if it is unset, and the leaves it that way instead of resetting it to 0.
In resolve.c:no_naptr_srv_sip_resolvehost() a proper SRV lookup function is defined, but not used at least for the t_relay() case. Perhaps change both functions in dns_cache.c to use no_naptr_srv_sip_resolvehost?
On 2013-09-27 at 13:42, Øyvind Kolbu wrote:
On 2013-09-27 at 11:49, Daniel-Constantin Mierla wrote:
Haven't got time to get back to it -- hope to happen soon.
I've taken a small peak and think I at least found some of the problem, but also got quite confused.
What is the relationship between dns_cache.c:dns_srv_sip_resolvehost() and dns_cache.c:dns_srv_sip_resolve()? They look very much copy and paste, with the same error in them. Both will only search for UDP records if *proto is not set. They also mangle the *proto value as they both set it to PROTO_UDP if it is unset, and the leaves it that way instead of resetting it to 0.
In resolve.c:no_naptr_srv_sip_resolvehost() a proper SRV lookup function is defined, but not used at least for the t_relay() case. Perhaps change both functions in dns_cache.c to use no_naptr_srv_sip_resolvehost?
The patch attached fixes the no NAPTR and no UDP case, but only when use_dns_failover is set to off. We usually have it on, but I can't recall why..
Anyhow the patch is rather trivial, just store *proto before overwriting it and restore it before calling no_naptr_srv_sip_resolvehost.
Hello,
thanks for digging further, I will check it and commit if all looks good.
Cheers, Daniel
On 9/29/13 5:55 PM, Øyvind Kolbu wrote:
On 2013-09-27 at 13:42, Øyvind Kolbu wrote:
On 2013-09-27 at 11:49, Daniel-Constantin Mierla wrote:
Haven't got time to get back to it -- hope to happen soon.
I've taken a small peak and think I at least found some of the problem, but also got quite confused.
What is the relationship between dns_cache.c:dns_srv_sip_resolvehost() and dns_cache.c:dns_srv_sip_resolve()? They look very much copy and paste, with the same error in them. Both will only search for UDP records if *proto is not set. They also mangle the *proto value as they both set it to PROTO_UDP if it is unset, and the leaves it that way instead of resetting it to 0.
In resolve.c:no_naptr_srv_sip_resolvehost() a proper SRV lookup function is defined, but not used at least for the t_relay() case. Perhaps change both functions in dns_cache.c to use no_naptr_srv_sip_resolvehost?
The patch attached fixes the no NAPTR and no UDP case, but only when use_dns_failover is set to off. We usually have it on, but I can't recall why..
Anyhow the patch is rather trivial, just store *proto before overwriting it and restore it before calling no_naptr_srv_sip_resolvehost.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 2013-09-30 at 09:36, Daniel-Constantin Mierla wrote:
Hello,
thanks for digging further, I will check it and commit if all looks good.
Found an unrelated bug while testing more. If using dns_cache and use_dns_failover=off, it will not resolve A/AAAA-only hosts.
Note that srv-lookups is still broken in the use_dns_failover=on case, as it only attempts one srv lookup, usually udp.
From the logs of a stock Kamailio lastest 4.0: DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(sip-services.uninett.no(23), 35), h=412 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(sip-services.uninett.no, 35) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(sip-services.uninett.no, 35, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding sip-services.uninett.no(23) 35 (flags=1) at 412 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(_sip._udp.sip-services.uninett.no(33), 33), h=64 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(_sip._udp.sip-services.uninett.no, 33) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._udp.sip-services.uninett.no, 33, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding _sip._udp.sip-services.uninett.no(33) 33 (flags=1) at 64 ERROR: <core> [resolve.c:1728]: sip_hostport2su(): ERROR: sip_hostport2su: could not resolve hostname: "sip-services.uninett.no" ERROR: tm [ut.h:337]: uri2dst2(): failed to resolve "sip-services.uninett.no" ERROR: tm [t_fwd.c:1534]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches DEBUG: tm [t_funcs.c:357]: t_relay_to(): ERROR:tm:t_relay_to: t_forward_nonack returned error DEBUG: tm [t_funcs.c:374]: t_relay_to(): -478 error reply generation delayed
And corresponding tcpdump: 27971+ NAPTR? sip-services.uninett.no. (41) 27971 0/1/0 (93) 57279+ SRV? _sip._udp.sip-services.uninett.no. (51) 57279 NXDomain 0/1/0 (103)
With the attached patch, it works. See logs:
DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(sip-services.uninett.no(23), 35), h=412 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(sip-services.uninett.no, 35) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(sip-services.uninett.no, 35, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding sip-services.uninett.no(23) 35 (flags=1) at 412 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(_sip._udp.sip-services.uninett.no(33), 33), h=64 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(_sip._udp.sip-services.uninett.no, 33) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._udp.sip-services.uninett.no, 33, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding _sip._udp.sip-services.uninett.no(33) 33 (flags=1) at 64 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(_sip._tcp.sip-services.uninett.no(33), 33), h=871 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(_sip._tcp.sip-services.uninett.no, 33) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._tcp.sip-services.uninett.no, 33, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding _sip._tcp.sip-services.uninett.no(33) 33 (flags=1) at 871 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(sip-services.uninett.no(23), 1), h=412 DEBUG: <core> [resolve.c:954]: get_record(): get_record: skipping 5 NS (p=0x82a6a59, end=0x82a6b86) DEBUG: <core> [resolve.c:970]: get_record(): get_record: parsing 9 ARs (p=0x82a6ac6, end=0x82a6b86) DEBUG: <core> [dns_cache.c:1779]: dns_get_related(): dns_get_related(0xb5d8a5f8 (sip-services.uninett.no, 1), 1, *0xb7c24e98) (0) DEBUG: <core> [dns_cache.c:872]: dns_cache_add_unsafe(): dns_cache_add: adding sip-services.uninett.no(23) 1 (flags=0) at 412
and new tcpdump: 61793+ NAPTR? sip-services.uninett.no. (41) 61793 0/1/0 (93) 46996+ SRV? _sip._udp.sip-services.uninett.no. (51) 46996 NXDomain 0/1/0 (103) 1104+ SRV? _sip._tcp.sip-services.uninett.no. (51) 1104 NXDomain 0/1/0 (103) 22158+ A? sip-services.uninett.no. (41) 22158 1/5/9 A sip-services.uninett.no (358)
Hello,
I'll check this one as well. Is this patch in addition to the previous one or combined?
Cheers, Daniel
On 9/30/13 10:16 AM, Øyvind Kolbu wrote:
On 2013-09-30 at 09:36, Daniel-Constantin Mierla wrote:
Hello,
thanks for digging further, I will check it and commit if all looks good.
Found an unrelated bug while testing more. If using dns_cache and use_dns_failover=off, it will not resolve A/AAAA-only hosts.
Note that srv-lookups is still broken in the use_dns_failover=on case, as it only attempts one srv lookup, usually udp.
From the logs of a stock Kamailio lastest 4.0: DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(sip-services.uninett.no(23), 35), h=412 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(sip-services.uninett.no, 35) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(sip-services.uninett.no, 35, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding sip-services.uninett.no(23) 35 (flags=1) at 412 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(_sip._udp.sip-services.uninett.no(33), 33), h=64 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(_sip._udp.sip-services.uninett.no, 33) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._udp.sip-services.uninett.no, 33, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding _sip._udp.sip-services.uninett.no(33) 33 (flags=1) at 64 ERROR: <core> [resolve.c:1728]: sip_hostport2su(): ERROR: sip_hostport2su: could not resolve hostname: "sip-services.uninett.no" ERROR: tm [ut.h:337]: uri2dst2(): failed to resolve "sip-services.uninett.no" ERROR: tm [t_fwd.c:1534]: t_forward_nonack(): ERROR: t_forward_nonack: failure to add branches DEBUG: tm [t_funcs.c:357]: t_relay_to(): ERROR:tm:t_relay_to: t_forward_nonack returned error DEBUG: tm [t_funcs.c:374]: t_relay_to(): -478 error reply generation delayed
And corresponding tcpdump: 27971+ NAPTR? sip-services.uninett.no. (41) 27971 0/1/0 (93) 57279+ SRV? _sip._udp.sip-services.uninett.no. (51) 57279 NXDomain 0/1/0 (103)
With the attached patch, it works. See logs:
DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(sip-services.uninett.no(23), 35), h=412 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(sip-services.uninett.no, 35) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(sip-services.uninett.no, 35, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding sip-services.uninett.no(23) 35 (flags=1) at 412 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(_sip._udp.sip-services.uninett.no(33), 33), h=64 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(_sip._udp.sip-services.uninett.no, 33) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._udp.sip-services.uninett.no, 33, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding _sip._udp.sip-services.uninett.no(33) 33 (flags=1) at 64 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(_sip._tcp.sip-services.uninett.no(33), 33), h=871 DEBUG: <core> [resolve.c:757]: get_record(): get_record: lookup(_sip._tcp.sip-services.uninett.no, 33) failed DEBUG: <core> [dns_cache.c:897]: dns_cache_mk_bad_entry(): dns_cache_mk_bad_entry(_sip._tcp.sip-services.uninett.no, 33, 60, 1) DEBUG: <core> [dns_cache.c:830]: dns_cache_add(): dns_cache_add: adding _sip._tcp.sip-services.uninett.no(33) 33 (flags=1) at 871 DEBUG: <core> [dns_cache.c:569]: _dns_hash_find(): dns_hash_find(sip-services.uninett.no(23), 1), h=412 DEBUG: <core> [resolve.c:954]: get_record(): get_record: skipping 5 NS (p=0x82a6a59, end=0x82a6b86) DEBUG: <core> [resolve.c:970]: get_record(): get_record: parsing 9 ARs (p=0x82a6ac6, end=0x82a6b86) DEBUG: <core> [dns_cache.c:1779]: dns_get_related(): dns_get_related(0xb5d8a5f8 (sip-services.uninett.no, 1), 1, *0xb7c24e98) (0) DEBUG: <core> [dns_cache.c:872]: dns_cache_add_unsafe(): dns_cache_add: adding sip-services.uninett.no(23) 1 (flags=0) at 412
and new tcpdump: 61793+ NAPTR? sip-services.uninett.no. (41) 61793 0/1/0 (93) 46996+ SRV? _sip._udp.sip-services.uninett.no. (51) 46996 NXDomain 0/1/0 (103) 1104+ SRV? _sip._tcp.sip-services.uninett.no. (51) 1104 NXDomain 0/1/0 (103) 22158+ A? sip-services.uninett.no. (41) 22158 1/5/9 A sip-services.uninett.no (358)
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Öyvind, As you are digging into the SRV code - can you try to come up with a description how it works?
I am particularly interested in how it handles IPv6 addresses and multiple A/AAAA records for one name.
Working on this in Asterisk as well as writing a new IETF draft about the IPv6 part...
/O
On 30.09.2013 10:37, Olle E. Johansson wrote:
Öyvind, As you are digging into the SRV code - can you try to come up with a description how it works?
I am particularly interested in how it handles IPv6 addresses and multiple A/AAAA records for one name.
OK, I'll write a small description. I've no sip-setup with IPv6 here, but can at least try the multiple A-records and see what it does.
Hello,
I applied the patch, thanks. For the future, please use tabs to indent the code, it is the format we use.
Is there any issue left from what you found? It was not clear after looking quickly over the last emails if something else still needs to be investigated.
Cheers, Daniel
On 9/30/13 10:32 AM, Øyvind Kolbu wrote:
On 30.09.2013 10:30, Daniel-Constantin Mierla wrote:
Hello,
I'll check this one as well. Is this patch in addition to the previous one or combined?
Combined. The only new is adding:
/* fallback all the way down to A/AAAA */ if (he==0) { he=dns_get_he(name,dns_flags); }
On 30.09.2013 11:20, Daniel-Constantin Mierla wrote:
Hello,
I applied the patch, thanks. For the future, please use tabs to indent the code, it is the format we use.
Thank you for committing it! I'll use tabs next time.
Is there any issue left from what you found? It was not clear after looking quickly over the last emails if something else still needs to be investigated.
srv lookups is still broken in the use_dns_failover=on, as it then calls ends up in dns_cache.c:dns_srv_sip_resolve(), which only does UDP lookup if a protocol is not specified. Should do something similar as resolve.c:no_naptr_srv_sip_resolvehost().
-
Daniel-Constantin Mierla -
Olle E. Johansson -
Øyvind Kolbu