17 Sep
2013
17 Sep
'13
2:13 p.m.
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
--
Øyvind Kolbu
17 Sep
17 Sep
3:08 p.m.
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
--
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 -
18 Sep
18 Sep
12:01 a.m.
Hello,
On 9/17/13 2:30 PM, Øyvind Kolbu wrote:
On 17.09.2013 14:08, Daniel-Constantin Mierla wrote:
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
--
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 -
Hello,
can you make a test with debug=3 and send the logs to me?
Sent, thanks!
10:33 a.m.
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.
--
Øyvind
11:55 a.m.
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pre…
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:
--
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 -
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.
12:32 p.m.
18 sep 2013 kl. 10:55 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pre…
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:
---
* Olle E Johansson - oej(a)edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
On 17.09.2013 23:01, Daniel-Constantin Mierla
wrote:
--
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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.
1:04 p.m.
On 18.09.2013 11:32, Olle E. Johansson wrote:
18 sep 2013 kl. 10:55 skrev Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>:
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.
--
Øyvind
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pre…
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?
1:17 p.m.
On 9/18/13 12:04 PM, Øyvind Kolbu wrote:
On 18.09.2013 11:32, Olle E. Johansson wrote:
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
--
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 -
18 sep 2013 kl. 10:55 skrev Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>:
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.
Hello,
to set the preference order for queries, see:
http://www.kamailio.org/wiki/cookbooks/devel/core#dns_sctp_pref_dns_tcp_pre…
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?
24 Sep
24 Sep
12:23 p.m.
On 18.09.2013 12:17, Daniel-Constantin Mierla wrote:
On 9/18/13 12:04 PM, Øyvind Kolbu wrote:
Hi,
any ideas?
--
Øyvind Kolbu
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.
27 Sep
27 Sep
12:49 p.m.
On 9/24/13 11:23 AM, Øyvind Kolbu wrote:
On 18.09.2013 12:17, Daniel-Constantin Mierla wrote:
Haven't got time to get back to it -- hope to happen soon.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
On 9/18/13 12:04 PM, Øyvind Kolbu wrote:
Hi,
any ideas? 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.
2:42 p.m.
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?
--
Øyvind Kolbu
29 Sep
29 Sep
6:55 p.m.
On 2013-09-27 at 13:42, Øyvind Kolbu wrote:
On 2013-09-27 at 11:49, Daniel-Constantin Mierla
wrote:
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.
--
Øyvind Kolbu
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?
30 Sep
30 Sep
10:36 a.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
On 2013-09-27 at 11:49, Daniel-Constantin Mierla
wrote:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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?
11:16 a.m.
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)
--
Øyvind Kolbu
11:30 a.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:32 a.m.
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);
}
--
Øyvind
11:37 a.m.
Ö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
11:45 a.m.
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.
--
Øyvind
12:20 p.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Trainings - Berlin, Nov 25-28; Miami, Nov 18-20, 2013
- more details about Kamailio trainings at http://www.asipto.com -
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);
}
1:04 p.m.
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().
--
Øyvind
4074
days inactive
4087
days old
20 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Olle E. Johansson -
Øyvind Kolbu