Re: [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: >> 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