29 Oct
2012
29 Oct
'12
5:33 p.m.
Hi All,
I am experiencing an issue when i try to contact xy(a)cisco.com.
I found that kamailio/sip-router can't resolve by default resolving way
a TCP + SRV records from domain cisco.com.
e.g. cisco.com
misi@alma:~$ host -t NAPTR cisco.com
cisco.com has no NAPTR record
misi@alma:~$ host -t SRV _sip._udp.cisco.com
Host _sip._udp.cisco.com not found: 3(NXDOMAIN)
misi@alma:~$ host -t SRV _sip._tcp.cisco.com
_sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com.
misi@alma:~$ host -t SRV _sips._tcp.cisco.com
_sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com.
I can't call xy(a)cisco.com because it does not exists an NAPTR record in
domain cisco.com,
and furthermore no SRV with udp.
But it exists sip+tcp record
and also exists an secure sip SRV, so sips+tcp record!
I read rfc3263
I find kamailio dns resolver is not working as it should according RFC3263.
http://tools.ietf.org/html/rfc3263
_If no NAPTR records are found, the client constructs SRV queries
for those transport protocols it supports, and does a query for each._
So kamailio should query all (udp, tcp, tls, sctp whatever) protocols.
Can anyone help/guide me to create a fix to this issue?
My plan is to create a patch to kamailio resolver, to correct and behave
according RFC3263.
Any help or guidance appreciated!
Thanks,
Misi
5 Nov
5 Nov
4:03 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Indeed, this is not implemented correctly.
If you fix it, the question is: what should be used if there are SRV
records for UDP and TCP?
AFAIK there is already a configuration option to choose the respective
NAPTR records according to local priority. These config options could be
reused.
See dns_udp_pref/dns_tcp_pref/... options in doc/dns.txt
regards
Klaus
On 29.10.2012 16:33, MÉSZÁROS Mihály wrote:
Hi All,
I am experiencing an issue when i try to contact xy(a)cisco.com.
I found that kamailio/sip-router can't resolve by default resolving way
a TCP + SRV records from domain cisco.com.
e.g. cisco.com
misi@alma:~$ host -t NAPTR cisco.com
cisco.com has no NAPTR record
misi@alma:~$ host -t SRV _sip._udp.cisco.com
Host _sip._udp.cisco.com not found: 3(NXDOMAIN)
misi@alma:~$ host -t SRV _sip._tcp.cisco.com
_sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com.
misi@alma:~$ host -t SRV _sips._tcp.cisco.com
_sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com.
I can't call xy(a)cisco.com because it does not exists an NAPTR record in
domain cisco.com,
and furthermore no SRV with udp.
But it exists sip+tcp record
and also exists an secure sip SRV, so sips+tcp record!
I read rfc3263
I find kamailio dns resolver is not working as it should according RFC3263.
http://tools.ietf.org/html/rfc3263
_If no NAPTR records are found, the client constructs SRV queries
for those transport protocols it supports, and does a query for each._
So kamailio should query all (udp, tcp, tls, sctp whatever) protocols.
Can anyone help/guide me to create a fix to this issue?
My plan is to create a patch to kamailio resolver, to correct and behave
according RFC3263.
Any help or guidance appreciated!
Thanks,
Misi
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
6 Nov
6 Nov
2:31 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Dear Klaus et al.
Exactly the same was in my mind.
So my plan is to sort the protocols using these dns_PROTO_pref values.
If the pref is the same to all protocols,
(like it should according to the RFC3263 dns lookup process)
then the order will be udp,tcp,tls,sctp.
Any other suggestions are welcome!
Thanks,
Misi
On 2012-11-05 15:03, Klaus Darilion wrote:
Indeed, this is not implemented correctly.
If you fix it, the question is: what should be used if there are SRV
records for UDP and TCP?
AFAIK there is already a configuration option to choose the respective
NAPTR records according to local priority. These config options could
be reused.
See dns_udp_pref/dns_tcp_pref/... options in doc/dns.txt
regards
Klaus
On 29.10.2012 16:33, MÉSZÁROS Mihály wrote:
> Hi All,
>
> I am experiencing an issue when i try to contact xy(a)cisco.com.
> I found that kamailio/sip-router can't resolve by default resolving way
> a TCP + SRV records from domain cisco.com.
>
> e.g. cisco.com
>
> misi@alma:~$ host -t NAPTR cisco.com
> cisco.com has no NAPTR record
> misi@alma:~$ host -t SRV _sip._udp.cisco.com
> Host _sip._udp.cisco.com not found: 3(NXDOMAIN)
> misi@alma:~$ host -t SRV _sip._tcp.cisco.com
> _sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com.
> misi@alma:~$ host -t SRV _sips._tcp.cisco.com
> _sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com.
>
>
> I can't call xy(a)cisco.com because it does not exists an NAPTR record in
> domain cisco.com,
> and furthermore no SRV with udp.
>
> But it exists sip+tcp record
> and also exists an secure sip SRV, so sips+tcp record!
>
> I read rfc3263
> I find kamailio dns resolver is not working as it should according
> RFC3263.
>
> http://tools.ietf.org/html/rfc3263
>
> _If no NAPTR records are found, the client constructs SRV queries
> for those transport protocols it supports, and does a query for
> each._
>
>
> So kamailio should query all (udp, tcp, tls, sctp whatever) protocols.
>
> Can anyone help/guide me to create a fix to this issue?
> My plan is to create a patch to kamailio resolver, to correct and behave
> according RFC3263.
>
> Any help or guidance appreciated!
>
> Thanks,
> Misi
>
>
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
5:38 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
2012/11/5 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Indeed, this is not implemented correctly.
What is not implemented correctly? It MUST be correctly implemented,
what is the exact problem? RFC 3263 is very clear in the steps to
perform (first NAPTR and when not present try SRV in order of
preperence based on local policy).
Could you please describe the exact issue in Kamailio about this?
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
5:44 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
2012/11/6 Iñaki Baz Castillo <ibc(a)aliax.net>et>:
2012/11/5 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
BTW, OverSIP behavior when routing a request to cisco.com:
DEBUG: <RFC3263 4212866> DNS NAPTR error resolving 'cisco.com':
dns_error_nodata
DEBUG: <RFC3263 4212866> no NAPTR records, performing SRV queries
DEBUG: <RFC3263 4212866> DNS SRV succeeded for domain 'cisco.com',
service 'sips' and protocol 'tcp'
DEBUG: <RFC3263 4212866> DNS A succeeded for domain 'vcsgw.cisco.com'
DEBUG: <RFC3263 4212866> DNS SRV succeeded for domain 'cisco.com',
service 'sip' and protocol 'tcp'
DEBUG: <RFC3263 4212866> DNS A succeeded for domain 'vcsgw.cisco.com'
DEBUG: <RFC3263 4212866> DNS SRV error resolving domain 'cisco.com',
service 'sip' and protocol 'udp': dns_error_nxdomain
DEBUG: <Proxy proxy_out 4212866> DNS result has multiple values, randomizing
DEBUG: <Proxy proxy_out 4212866> trying target 1 of 2: tls:64.103.25.132:5061
DEBUG: <SIP TLS IPv4 client> TLS handshake not completed yet, waiting
before sending the message
DEBUG: <SIP TLS IPv4 client> received certificate num 1 from server
DEBUG: <SIP TLS IPv4 client> TLS connection established to 64.103.25.132:5061
DEBUG: <SIP TLS IPv4 client> running
OverSIP::SipEvents.on_server_tls_handshake()...
INFO: <SipEvents> [user] validating TLS connection to IP 64.103.25.132
and port 5061
NOTICE: <SipEvents> [user] server provides an invalid TLS certificate
with SIP identities ["tandberg"] (TLS error: 18, description: "self
signed certificate")
It was hard to properly implement full RFC 3263 but it's done. What is
the exact issue in Kamailio with this?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Indeed, this is not implemented correctly.
What is not implemented correctly? It MUST be correctly implemented,
what is the exact problem? RFC 3263 is very clear in the steps to
perform (first NAPTR and when not present try SRV in order of
preperence based on local policy).
Could you please describe the exact issue in Kamailio about this?
Thanks a lot.
7:31 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
On 06.11.2012 16:38, Iñaki Baz Castillo wrote:
2012/11/5 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
It is like described in the first email:
Kamailio does the following lookups:
1. NAPTR cisco.com (no result)
2. SRV _sip._udp.cisco.com (NXDOMAIN)
3. A cisco.com -> Bingo -> use SIP over UDP to Cisco's web server :-(
regards
Klaus
Indeed, this is not implemented correctly.
What is not implemented correctly? It MUST be correctly implemented,
what is the exact problem? RFC 3263 is very clear in the steps to
perform (first NAPTR and when not present try SRV in order of
preperence based on local policy).
Could you please describe the exact issue in Kamailio about this?
7:39 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
2012/11/6 Klaus Darilion <klaus.mailinglists(a)pernau.at>at>:
Kamailio does the following lookups:
1. NAPTR cisco.com (no result)
2. SRV _sip._udp.cisco.com (NXDOMAIN)
3. A cisco.com -> Bingo -> use SIP over UDP to Cisco's web server :-(
Then really wrong...
After NAPTR query (with no result) it should look for SRV records for
TLS, TCP and then UDP (maybe also SCTP) in an order configured by
local policy (Kamailio DNS settings).
This is really clear in RFC 3263 section 4.1:
If no NAPTR records are found, the client constructs SRV queries for
those transport protocols it supports, and does a query for each.
Queries are done using the service identifier "_sip" for SIP URIs and
"_sips" for SIPS URIs. A particular transport is supported if the
query is successful. The client MAY use any transport protocol it
desires which is supported by the server.
If no SRV records are found, the client SHOULD use TCP for a SIPS
URI, and UDP for a SIP URI. However, another transport protocol,
such as TCP, MAY be used if the guidelines of SIP mandate it for this
particular request.
Why is this not implemented?
Issue open at http://sip-router.org/tracker/index.php?do=details&task_id=253
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12 Nov
12 Nov
5:50 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Hi,
I made some progress. As I stated before, I made a patch and submitted
to git branch misi/dns_srv.
I tested with dns cache. It works for me.
I made it also available for case if "no dns cache" is used too,
but it isn't tested yet.
Please review my commit, and let me know if any corrections needed.
Any suggestion, comment highly appreciated!
Please also let me know even if you find my code OK and i can merge it
to the master.
Current status:
If there is no NAPTR record then based on the dns_/protocol/_pref scores
it sort the list of the sr supported protocols, and it tries protocols
to resolve SRV.
It stops the loop and returns, if it founds the first most preferred and
available/so DNS SRV exists for the protocol/ record.
I will appreciate if anyone can help me to explain how can i made future
progress with this SRV issue.
My problem is, that i don't know how to iterate and fallback to other
preferred and available protocols, so keep the state of the failed
protocols.
How can i save state and fallback if the access the remote side with the
currently selected SRV protocol failed so fall back to second,third..
available and preferred protocol.
Many thanks,
Misi
On 2012-11-05 15:03, Klaus Darilion wrote:
Indeed, this is not implemented correctly.
If you fix it, the question is: what should be used if there are SRV
records for UDP and TCP?
AFAIK there is already a configuration option to choose the respective
NAPTR records according to local priority. These config options could
be reused.
See dns_udp_pref/dns_tcp_pref/... options in doc/dns.txt
regards
Klaus
On 29.10.2012 16:33, MÉSZÁROS Mihály wrote:
> Hi All,
>
> I am experiencing an issue when i try to contact xy(a)cisco.com.
> I found that kamailio/sip-router can't resolve by default resolving way
> a TCP + SRV records from domain cisco.com.
>
> e.g. cisco.com
>
> misi@alma:~$ host -t NAPTR cisco.com
> cisco.com has no NAPTR record
> misi@alma:~$ host -t SRV _sip._udp.cisco.com
> Host _sip._udp.cisco.com not found: 3(NXDOMAIN)
> misi@alma:~$ host -t SRV _sip._tcp.cisco.com
> _sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com.
> misi@alma:~$ host -t SRV _sips._tcp.cisco.com
> _sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com.
>
>
> I can't call xy(a)cisco.com because it does not exists an NAPTR record in
> domain cisco.com,
> and furthermore no SRV with udp.
>
> But it exists sip+tcp record
> and also exists an secure sip SRV, so sips+tcp record!
>
> I read rfc3263
> I find kamailio dns resolver is not working as it should according
> RFC3263.
>
> http://tools.ietf.org/html/rfc3263
>
> _If no NAPTR records are found, the client constructs SRV queries
> for those transport protocols it supports, and does a query for
> each._
>
>
> So kamailio should query all (udp, tcp, tls, sctp whatever) protocols.
>
> Can anyone help/guide me to create a fix to this issue?
> My plan is to create a patch to kamailio resolver, to correct and behave
> according RFC3263.
>
> Any help or guidance appreciated!
>
> Thanks,
> Misi
>
>
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
14 Nov
14 Nov
1:51 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Hello,
On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
Hi,
I made some progress. As I stated before, I made a patch and submitted
to git branch misi/dns_srv.
I tested with dns cache. It works for me.
I made it also available for case if "no dns cache" is used too,
but it isn't tested yet.
Please review my commit, and let me know if any corrections needed.
if nobody does
it meanwhile, I can look over it next week and also check
properly what's all about this discussion, currently being out of the
office.
Cheers,
Daniel
Any suggestion, comment highly appreciated!
Please also let me know even if you find my code OK and i can merge it
to the master.
Current status:
If there is no NAPTR record then based on the dns_/protocol/_pref
scores it sort the list of the sr supported protocols, and it tries
protocols to resolve SRV.
It stops the loop and returns, if it founds the first most preferred
and available/so DNS SRV exists for the protocol/ record.
I will appreciate if anyone can help me to explain how can i made
future progress with this SRV issue.
My problem is, that i don't know how to iterate and fallback to other
preferred and available protocols, so keep the state of the failed
protocols.
How can i save state and fallback if the access the remote side with
the currently selected SRV protocol failed so fall back to
second,third.. available and preferred protocol.
Many thanks,
Misi
On 2012-11-05 15:03, Klaus Darilion wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Indeed, this is not implemented correctly.
If you fix it, the question is: what should be used if there are SRV
records for UDP and TCP?
AFAIK there is already a configuration option to choose the
respective NAPTR records according to local priority. These config
options could be reused.
See dns_udp_pref/dns_tcp_pref/... options in doc/dns.txt
regards
Klaus
On 29.10.2012 16:33, MÉSZÁROS Mihály wrote:
> Hi All,
>
> I am experiencing an issue when i try to contact xy(a)cisco.com.
> I found that kamailio/sip-router can't resolve by default resolving way
> a TCP + SRV records from domain cisco.com.
>
> e.g. cisco.com
>
> misi@alma:~$ host -t NAPTR cisco.com
> cisco.com has no NAPTR record
> misi@alma:~$ host -t SRV _sip._udp.cisco.com
> Host _sip._udp.cisco.com not found: 3(NXDOMAIN)
> misi@alma:~$ host -t SRV _sip._tcp.cisco.com
> _sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com.
> misi@alma:~$ host -t SRV _sips._tcp.cisco.com
> _sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com.
>
>
> I can't call xy(a)cisco.com because it does not exists an NAPTR record in
> domain cisco.com,
> and furthermore no SRV with udp.
>
> But it exists sip+tcp record
> and also exists an secure sip SRV, so sips+tcp record!
>
> I read rfc3263
> I find kamailio dns resolver is not working as it should according
> RFC3263.
>
> http://tools.ietf.org/html/rfc3263
>
> _If no NAPTR records are found, the client constructs SRV queries
> for those transport protocols it supports, and does a query for
> each._
>
>
> So kamailio should query all (udp, tcp, tls, sctp whatever) protocols.
>
> Can anyone help/guide me to create a fix to this issue?
> My plan is to create a patch to kamailio resolver, to correct and
> behave
> according RFC3263.
>
> Any help or guidance appreciated!
>
> Thanks,
> Misi
>
>
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev(a)lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
19 Nov
19 Nov
11:18 a.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Hi Daniel,
On 2012-11-14 12:51, Daniel-Constantin Mierla wrote:
Hello,
On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
After you had time to review it, please let me know your thoughts.
Many thanks,
Misi
Hi,
I made some progress. As I stated before, I made a patch and
submitted to git branch misi/dns_srv.
I tested with dns cache. It works for me.
I made it also available for case if "no dns cache" is used too,
but it isn't tested yet.
Please review my commit, and let me know if any corrections needed.
if nobody does
it meanwhile, I can look over it next week and also
check properly what's all about this discussion, currently being out
of the office.
30 Nov
30 Nov
10:07 a.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Hello,
On 11/19/12 10:18 AM, MÉSZÁROS Mihály wrote:
Hi Daniel,
On 2012-11-14 12:51, Daniel-Constantin Mierla wrote:
unfortunately I had no time to look at it yet. Hopefully I will find
some soon.
Btw, is it complete? IIRC, I saw something like it still has to be extended.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
After you had time to review it, please let me know your thoughts.
Hi,
I made some progress. As I stated before, I made a patch and
submitted to git branch misi/dns_srv.
I tested with dns cache. It works for me.
I made it also available for case if "no dns cache" is used too,
but it isn't tested yet.
Please review my commit, and let me know if any corrections needed.
if nobody does
it meanwhile, I can look over it next week and also
check properly what's all about this discussion, currently being out
of the office.
11:31 a.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Hi,
On 2012-11-30 09:07, Daniel-Constantin Mierla wrote:
Hello,
On 11/19/12 10:18 AM, MÉSZÁROS Mihály wrote:
It is complete and working patch.
If there are no NAPTR records to a domain, then according to the local
protocol preference it orders protocols and it tries to resolve SRV
records according this ordered list. If there is no order then the order
is udp,tcp,tls,sctp,..
SRV records are resolved in order Kamailio dns protocol preference.
My algorithm picks and returns with the first protocol resolvable SRV
record, so it sets from SRV the port and protocol.
(Of course if there are no SRV at all then it fallbacks to host
resolving so dns "A" record.)
It is big step forward comparing to current Kamailio behavior where it
is using strictly udp only and after it stops searching SRV records at
all, and go for "A" record!
As i wrote in my patch announcing email it is a step further on the way
to conforming with RFC3263, but my patch not handling fallback if there
are SRV-s for multiple protocols in DNS.
In such case only and only if the first protocol is temporary not
available or fails we are not falling back to other protocol but falling
back to host resolving so "A" record (and/or AAAA).
Can you send meg the iirc message what was there exactly?
Is there any other problem in it?
I guess no just what i explained above.
I am eagerly waiting your review and comment.
Thanks in advance!
Misi
Hi Daniel,
On 2012-11-14 12:51, Daniel-Constantin Mierla wrote:
unfortunately I had no time to look at it yet. Hopefully I will find
some soon.
Btw, is it complete? IIRC, I saw something like it still has to be
extended.
Hello,
On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
After you had time to review it, please let me know your thoughts. Hi,
I made some progress. As I stated before, I made a patch and
submitted to git branch misi/dns_srv.
I tested with dns cache. It works for me.
I made it also available for case if "no dns cache" is used too,
but it isn't tested yet.
Please review my commit, and let me know if any corrections needed.
if nobody does
it meanwhile, I can look over it next week and also
check properly what's all about this discussion, currently being out
of the office.
4 Dec
4 Dec
6:47 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Hello,
I was looking to the patch and I spotted that you didn't assign anymore
a value to he variable -- next is the specific part of the diff:
- /* fallback to normal srv lookup */
- he=srv_sip_resolvehost(name, 0, port, proto, 0, 0);
+ /* fallback to srv lookup */
+ no_naptr_srv_sip_resolvehost(name,port,proto);
Shouldn't be like: he = no_naptr_srv_sip_resolvehost(name,port,proto);
Cheers,
Daniel
On 11/30/12 10:31 AM, MÉSZÁROS Mihály wrote:
Hi,
On 2012-11-30 09:07, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Hello,
On 11/19/12 10:18 AM, MÉSZÁROS Mihály wrote:
It is complete and working patch.
If there are no NAPTR records to a domain, then according to the local
protocol preference it orders protocols and it tries to resolve SRV
records according this ordered list. If there is no order then the
order is udp,tcp,tls,sctp,..
SRV records are resolved in order Kamailio dns protocol preference.
My algorithm picks and returns with the first protocol resolvable SRV
record, so it sets from SRV the port and protocol.
(Of course if there are no SRV at all then it fallbacks to host
resolving so dns "A" record.)
It is big step forward comparing to current Kamailio behavior where it
is using strictly udp only and after it stops searching SRV records at
all, and go for "A" record!
As i wrote in my patch announcing email it is a step further on the
way to conforming with RFC3263, but my patch not handling fallback if
there are SRV-s for multiple protocols in DNS.
In such case only and only if the first protocol is temporary not
available or fails we are not falling back to other protocol but
falling back to host resolving so "A" record (and/or AAAA).
Can you send meg the iirc message what was there exactly?
Is there any other problem in it?
I guess no just what i explained above.
I am eagerly waiting your review and comment.
Thanks in advance!
Misi Hi Daniel,
On 2012-11-14 12:51, Daniel-Constantin Mierla wrote:
unfortunately I had no time to look at it yet. Hopefully I will find
some soon.
Btw, is it complete? IIRC, I saw something like it still has to be
extended.
Hello,
On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
> Hi,
>
> I made some progress. As I stated before, I made a patch and
> submitted to git branch misi/dns_srv.
> I tested with dns cache. It works for me.
>
> I made it also available for case if "no dns cache" is used too,
> but it isn't tested yet.
>
> Please review my commit, and let me know if any corrections needed.
if nobody does it meanwhile, I can look over it next week and also
check properly what's all about this discussion, currently being
out of the office.
After you had time to review it, please let me know your thoughts.
5 Dec
5 Dec
2:07 p.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
Hi Daniel
I wrote in my first patch announcing email, that i didn't test the
patched dns resolution without cache.
I only tested with dns cache.
This is the reason why i didn't recognize this problem.
You are right I made a mistake, but now it is corrected.
Many Thanks,
Misi
On 2012-12-04 17:47, Daniel-Constantin Mierla wrote:
Hello,
I was looking to the patch and I spotted that you didn't assign
anymore a value to he variable -- next is the specific part of the diff:
- /* fallback to normal srv lookup */
- he=srv_sip_resolvehost(name, 0, port, proto, 0, 0);
+ /* fallback to srv lookup */
+ no_naptr_srv_sip_resolvehost(name,port,proto);
Shouldn't be like: he = no_naptr_srv_sip_resolvehost(name,port,proto);
Cheers,
Daniel
On 11/30/12 10:31 AM, MÉSZÁROS Mihály wrote:
Hi,
On 2012-11-30 09:07, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda Hello,
On 11/19/12 10:18 AM, MÉSZÁROS Mihály wrote:
It is complete and working patch.
If there are no NAPTR records to a domain, then according to the
local protocol preference it orders protocols and it tries to resolve
SRV records according this ordered list. If there is no order then
the order is udp,tcp,tls,sctp,..
SRV records are resolved in order Kamailio dns protocol preference.
My algorithm picks and returns with the first protocol resolvable SRV
record, so it sets from SRV the port and protocol.
(Of course if there are no SRV at all then it fallbacks to host
resolving so dns "A" record.)
It is big step forward comparing to current Kamailio behavior where
it is using strictly udp only and after it stops searching SRV
records at all, and go for "A" record!
As i wrote in my patch announcing email it is a step further on the
way to conforming with RFC3263, but my patch not handling fallback if
there are SRV-s for multiple protocols in DNS.
In such case only and only if the first protocol is temporary not
available or fails we are not falling back to other protocol but
falling back to host resolving so "A" record (and/or AAAA).
Can you send meg the iirc message what was there exactly?
Is there any other problem in it?
I guess no just what i explained above.
I am eagerly waiting your review and comment.
Thanks in advance!
Misi Hi Daniel,
On 2012-11-14 12:51, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
>> Hi,
>>
>> I made some progress. As I stated before, I made a patch and
>> submitted to git branch misi/dns_srv.
>> I tested with dns cache. It works for me.
>>
>> I made it also available for case if "no dns cache" is used too,
>> but it isn't tested yet.
>>
>> Please review my commit, and let me know if any corrections needed.
> if nobody does it meanwhile, I can look over it next week and also
> check properly what's all about this discussion, currently being
> out of the office.
>
After you had time to review it, please let me know your thoughts.
unfortunately I
had no time to look at it yet. Hopefully I will find
some soon.
Btw, is it complete? IIRC, I saw something like it still has to be
extended.
19 Nov
19 Nov
11:41 a.m.
New subject: [sr-dev] dns resolver issue (RFC3263)
2012/11/14 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
On 11/12/12 10:50 AM, MÉSZÁROS Mihály wrote:
Hi,
I made some progress. As I stated before, I made a patch and submitted to
git branch misi/dns_srv.
I tested with dns cache. It works for me.
I made it also available for case if "no dns cache" is used too,
but it isn't tested yet.
Please review my commit, and let me know if any corrections needed.
if nobody does it meanwhile, I can look over it next week and also check
properly what's all about this discussion, currently being out of the
office.
Hi, I will try to get some time this week to try the patch. I will
play with custom and "complex" DNS NAPTR and SRV entries to analyze
the behavior with the patch.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
4376
days inactive
4413
days old
14 comments
4 participants
participants (4)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
MÉSZÁROS Mihály