Re: [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: >>> 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(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev