Hello,
ok, if the tests went fine then you can merge the patches to the master
branch. I will test it from there in short time.
Thanks,
Daniel
On 12/16/12 1:28 PM, MÉSZÁROS Mihály wrote:
Hi Daniel,
You have absolutely right, it has to be tested it without cache.
I thought someone is using it that way and will help to test it,
anyhow I made the test myself now.
I have tested sip-router without DNS CACHE and after this correction:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=7ce7d6413b45e7e9df190167e7faba8c10f96492
Now it seems to be working correctly.
So I tested it, and i couldn't experience any issue with it.
It will be more safe if others (like IBC,Klauss) can apply it to any
testing baranch and confirm that they have no issue with it.
If you want to Test it yourself i can wait for the next major release.
(After it please merge it to master.)
Many Thanks,
Misi
On 2012-12-10 10:26, Daniel-Constantin Mierla wrote:
Hello,
one thing keeps it back for now - you said that you didn't tested
without cache. So that has to be reviewed as well, it is a patch for
core and cannot be overlooked. If you can test it and report the
results, then it can speed up. For me it will take a bit of time to
get to testing it, but I will before the next major release.
Cheers,
Daniel
On 12/10/12 9:37 AM, MÉSZÁROS Mihály wrote:
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
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -http://www.asipto.com
http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
