[reSIProcate] How does a client build a DNS lookup that restr icts the responses to UDP?

[Byron Campen]

	In 4.1, the "Otherwise" at the beginning of the third paragraph  
applies to the rest of sec 4.1. If the transport is specified, we  
skip the meat of 4.1 entirely, and never perform a NAPTR lookup. In  
4.2, it says that if we didn't do any NAPTR processing in 4.1 (note  
the extra "because a transport was specified explicitly") , we  
synthesize an SRV to look up.

Best regards,
Byron Campen

> Good deal.  I missed that in the RFC.  On another look at sec. 4.1,  
> I see it
> doesn't say to not use NAPTR if the transport is specified but the  
> port is
> not.  Rather, I see it just says to use NAPTR if neither the  
> transport or
> port are specified.  So, if the transport is specified, it just  
> uses the
> default SRV for _sip._udp?  If there's a line that explictly says  
> how this
> works regarding the default SRV record, that will help.
>
> Thanks, yall have helped a lot.
> Dave
>
>
> -----Original Message-----
> From: Byron Campen [mailto:bcampen at estacado.net]
> Sent: Thursday, December 07, 2006 1:07 PM
> To: Dave Mason
> Cc: resiprocate-devel at list.resiprocate.org
> Subject: Re: [reSIProcate] How does a client build a DNS lookup  
> that restr
> icts the responses to UDP?
>
> 	This is the behavior specified in RFC 3263, so DNS admins should be
> expecting it (although 3263 can be a little tricky to wade through).
>
> Best regards,
> Byron Campen
>
>> Hi, I just found a quick followup...
>>
>> I find that if I do a lookup with a URI such as
>> "sip:user at domain.com;transport=udp", the library ignores the NAPTR
>> records and chooses the _sip._udp.<domain.com> SRV record.  Thus, if
>> the DNS response has a NAPTR with a different preference for UDP such
>> as _sip2._udp.<domain.com>, it will be ignored in favor of the
>> default.
>>
>> Is this a known condition that DNS admins will take into account, or
>> should I first do a lookup without it, and search those results for
>> UDP transports?
>> If none are found, then I do a lookup with ";transport=udp"
>> appended to
>> guarantee a UDP response?  (I hate to do two lookups if I don't need
>> to.) What's the proper way to use the library (DnsInterface class)  
>> for
>> this case?
>>
>> Regards,
>> Dave
>>
>>
>> -----Original Message-----
>> From: Byron Campen [mailto:bcampen at estacado.net]
>> Sent: Tuesday, December 05, 2006 5:04 PM
>> To: Dave Mason
>> Cc: resiprocate-devel at list.resiprocate.org
>> Subject: Re: [reSIProcate] How does a client build a DNS lookup that
>> restricts the responses to UDP?
>>
>> 	Well, you can always do sip:user at domain.com;transport=udp. Also, if
>> your stack doesn't support TCP, it should use UDP instead. Lastly, if
>> there are no TCP SRVs in DNS, you should also get UDP results.
>>
>> Best regards,
>> Byron Campen
>>
>>> Hi,
>>>
>>> I find that if a DNS server is set up with NAPTR records for a  
>>> domain
>>> that specify TLS/TCP is most preferred, then TCP, the UDP last,  
>>> and a
>>> client does a DNS lookup for sip:user at domain.com (through
>>> DnsInterface), the DNS server only returns records for TLS/TCP.
>>>
>>> How do you configure the lookup on the client side to ask for only
>>> UDP records, even if they are least preferred on the server?
>>>
>>> Regards,
>>> Dave
>>> _______________________________________________
>>> resiprocate-devel mailing list
>>> resiprocate-devel at list.resiprocate.org
>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061207/3a65088f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20061207/3a65088f/attachment.bin>