[SR-Users] [sr-dev] dns resolver issue (RFC3263)

[Daniel-Constantin Mierla]

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.

Cheers,
Daniel

> Any suggestion, comment highly appreciated!
>
> Please also let me know even if you find my code OK and i can merge it 
> to the master.
>
> Current status:
> If there is no NAPTR record then based on the dns_/protocol/_pref 
> scores it sort the list of the sr supported protocols,  and it tries 
> protocols to resolve SRV.
> It stops the loop and returns, if it founds the first most preferred 
> and available/so DNS SRV exists for the protocol/ record.
>
> I will appreciate if anyone can help me to explain how can i made 
> future progress with this SRV issue.
> My problem is, that i don't know how to iterate and fallback to other 
> preferred and available protocols, so keep the state of the failed 
> protocols.
> How can i save state and fallback if the access the remote side with 
> the currently selected SRV protocol failed so fall back to 
> second,third.. available and preferred protocol.
>
> Many thanks,
> Misi
>
> On 2012-11-05 15:03, Klaus Darilion wrote:
>> Indeed, this is not implemented correctly.
>>
>> If you fix it, the question is: what should be used if there are SRV 
>> records for UDP and TCP?
>>
>> AFAIK there is already a configuration option to choose the 
>> respective NAPTR records according to local priority. These config 
>> options could be reused.
>>
>> See dns_udp_pref/dns_tcp_pref/... options in doc/dns.txt
>>
>> regards
>> Klaus
>>
>> On 29.10.2012 16:33, MÉSZÁROS Mihály wrote:
>>> Hi All,
>>>
>>> I am experiencing an issue when i try to contact xy at cisco.com.
>>> I found that kamailio/sip-router can't resolve by default resolving way
>>> a TCP + SRV records from domain cisco.com.
>>>
>>> e.g. cisco.com
>>>
>>>     misi at alma:~$ host -t NAPTR cisco.com
>>>     cisco.com has no NAPTR record
>>>     misi at alma:~$ host -t SRV _sip._udp.cisco.com
>>>     Host _sip._udp.cisco.com not found: 3(NXDOMAIN)
>>>     misi at alma:~$ host -t SRV _sip._tcp.cisco.com
>>>     _sip._tcp.cisco.com has SRV record 1 0 5060 vcsgw.cisco.com.
>>>     misi at alma:~$ host -t SRV _sips._tcp.cisco.com
>>>     _sips._tcp.cisco.com has SRV record 1 0 5061 vcsgw.cisco.com.
>>>
>>>
>>> I can't call xy at cisco.com because it does not exists an NAPTR record in
>>> domain cisco.com,
>>> and furthermore no SRV with udp.
>>>
>>> But it exists sip+tcp record
>>> and also exists an secure sip SRV, so sips+tcp record!
>>>
>>> I read rfc3263
>>> I find kamailio dns resolver is not working as it should according 
>>> RFC3263.
>>>
>>> http://tools.ietf.org/html/rfc3263
>>>
>>>     _If no NAPTR records are found, the client constructs SRV queries
>>>     for those transport protocols it supports, and does a query for 
>>> each._
>>>
>>>
>>> So kamailio should query all (udp, tcp, tls, sctp whatever) protocols.
>>>
>>> Can anyone help/guide me to create a fix to this issue?
>>> My plan is to create a patch to kamailio resolver, to correct and 
>>> behave
>>> according RFC3263.
>>>
>>> Any help or guidance appreciated!
>>>
>>> Thanks,
>>> Misi
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20121114/3f374db5/attachment-0001.htm>