[sr-dev] dns resolver issue (RFC3263)

[MÉSZÁROS Mihály]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20121205/301faa40/attachment.htm>