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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

2012/11/5 Klaus Darilion klaus.mailinglists@pernau.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@aliax.net

On 06.11.2012 16:38, Iñaki Baz Castillo wrote:

2012/11/5 Klaus Darilion klaus.mailinglists@pernau.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?

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

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@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@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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.

Many thanks, Misi

On 2012-11-19 10:41, Iñaki Baz Castillo wrote:

2012/11/14 Daniel-Constantin Mierlamiconda@gmail.com:

...

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.

Hi,

I am just wondering do you have any comment on my patch? Do you have a little time to test it?

Thanks, Misi

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:

...

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.

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

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:

...

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:

...

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.

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

Hello,

one thing keeps it back for now - you said that you didn't tested without cache. So that has to be reviewed as well, it is a patch for core and cannot be overlooked. If you can test it and report the results, then it can speed up. For me it will take a bit of time to get to testing it, but I will before the next major release.

Cheers, Daniel

On 12/10/12 9:37 AM, MÉSZÁROS Mihály wrote:

Hi All,

Any other issue or comment or request for correction? When can i expect to submit it to master tree?

Thanks, Misi

On 2012-12-05 13:07, MÉSZÁROS Mihály wrote:

...

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:

...

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: > 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.

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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Hello,

ok, if the tests went fine then you can merge the patches to the master branch. I will test it from there in short time.

Thanks, Daniel

On 12/16/12 1:28 PM, MÉSZÁROS Mihály wrote:

Hi Daniel,

You have absolutely right, it has to be tested it without cache. I thought someone is using it that way and will help to test it, anyhow I made the test myself now.

I have tested sip-router without DNS CACHE and after this correction: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=7ce...

Now it seems to be working correctly. So I tested it, and i couldn't experience any issue with it.

It will be more safe if others (like IBC,Klauss) can apply it to any testing baranch and confirm that they have no issue with it.

If you want to Test it yourself i can wait for the next major release. (After it please merge it to master.)

Many Thanks, Misi

On 2012-12-10 10:26, Daniel-Constantin Mierla wrote:

...

Hello,

one thing keeps it back for now - you said that you didn't tested without cache. So that has to be reviewed as well, it is a patch for core and cannot be overlooked. If you can test it and report the results, then it can speed up. For me it will take a bit of time to get to testing it, but I will before the next major release.

Cheers, Daniel

On 12/10/12 9:37 AM, MÉSZÁROS Mihály wrote:

...

Hi All,

Any other issue or comment or request for correction? When can i expect to submit it to master tree?

Thanks, Misi

On 2012-12-05 13:07, MÉSZÁROS Mihály wrote:

...

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: > 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: >>> 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. > 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

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda