Mikael Magnusson <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 06, 2006 at 12:29:15PM +0100, Fredrik Thulin wrote:
>> 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
>   "_sip".

Well, OK then. The transport=xxx Request-URI parameter must be based on 
backwards compatibility with RFC2543 clients alltogether, and is 
therefor of less importance.

That's good, because with the exception of TLS (signalled through SIPS, 
not transport=tls) I couldn't understand why the client should be able 
to specify which transport two servers perhaps several SIP hops away 
from the client should use for a particular request in the first place.

I have some half baked code from todays grunting over this issue - I'll 
see if anything good can come out of it. I will definitely fix the issue 
with only choosing one transport per request.


Yxa-devel mailing list

Reply via email to