[sr-dev] dns resolver issue (RFC3263)

[MÉSZÁROS Mihály]

Hi All,

Any other issue or comment or request for correction?
When can i expect to submit it to master tree?

Thanks,
Misi

On 2012-12-05 13:07, MÉSZÁROS Mihály wrote:
> 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

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