On Mon, Nov 06, 2006 at 12:29:15PM +0100, Fredrik Thulin wrote:
> Mikael Magnusson <[EMAIL PROTECTED]> wrote:

> >Section 4.1 "Selecting Transport Protocol" in RFC 3263 is completed if
> >the URI contains a transport parameter. There is no reason to select
> >transport protocol using NAPTR. And you should only lookup SRV
> >records for the selected transport protocol.
> Let me illustrate the need to perform NAPTR/SRV resolving even if there 
> is a transport parameter in the Request-URI using an example : the 
> domain sip.su.se.
> You HAVE to perform the NAPTR lookup to find out which ports at which 
> hosts (and their order/preference) you should send your request to.
> (SRV records present in every domain is explicitly for backwards 
> compatibility witf RFC2543 clients, so I don't think their presence is 
> relevant to this discussion)

Maybe it's for backwards compatibility, but they are in fact used
if the SIP URI contains a transport parameter according
to section 4.2 "Determining Port and IP Address":

   If the TARGET was not a numeric IP address, and no port was present
   in the URI, the client performs an SRV query on the record returned
   from the NAPTR processing of Section 4.1, if such processing was
   performed.  If it was not, because a transport was specified
   explicitly, the client performs an SRV query for that specific
   transport, using the service identifier "_sips" for SIPS URIs.  For a
   SIP URI, if the client wishes to use TLS, it also uses the service
   identifier "_sips" for that specific transport, otherwise, it uses


Yxa-devel mailing list

Reply via email to