[sr-dev] dns resolver issue (RFC3263)

[Daniel-Constantin Mierla]

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/20121204/3447f3de/attachment.htm>