Indeed, this is not implemented correctly.

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 >

Hi Daniel, On 2012-11-14 12:51, Daniel-Constantin Mierla wrote: After you had time to review it, please let me know your thoughts.

Hi, On 2012-11-30 09:07, Daniel-Constantin Mierla 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