Re: [Yxa-devel] URI transport parameter
Fredrik Thulin <[EMAIL PROTECTED]> wrote: ... > 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. I spent the better part of this week (apart from yesterday, when I was at the Erlang User Conference) updating the RFC3263 #4.1 and #4.2 implementation in sipdst.erl to be more technically correct. The new version I just checked in looks at the transport parameter for all different variants of URLs (IP, non-IP, NAPTR found, NAPTR not found), and also always just return entrys of the most preferred transport (tm). I improved the testability of the code, and test code coverage went from 46.6% to 89.8%. The rest of this module can't be tested automatically before it becomes possible to set up a fake configuration environment when testing, something I'm very keen to do. /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] URI transport parameter
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. /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] URI transport parameter
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 "_sip". Mikael ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] URI transport parameter
Mikael Magnusson <[EMAIL PROTECTED]> wrote: > On Mon, Nov 06, 2006 at 11:03:01AM +0100, Fredrik Thulin wrote: > >> >> What if you type in an address of "sip:[EMAIL PROTECTED];transport=udp" >> in your user agent, but example.org has NAPTR/SRV records giving >> precedence to TCP? When your user agent sends the request to your >> YXA proxy (presumably using UDP), what transport should the YXA >> server use after it resolves the NAPTR/SRV records of example.org >> and sees that the UAC has requested one protocol, but example.org >> prefers to be contacted using another? >> >> I'll have to think about that at least over lunch. >> >> /Fredrik >> > > I assume that the user agent is configured with a pre-set route set > (AKA outbound proxy), otherwise the user agent should send the request > directly to the example.org server. Yes, this is more the normal case than not. > 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) > Btw, when using NAPTR you should select the most preferred transport > protocol, and not use all. > > RFC 3263 4.1 > The NAPTR processing as described in RFC 2915 will result in the > discovery of the most preferred transport protocol of the server > that is supported by the client, as well as an SRV record for the > server. Yes, I realized that a while ago after the question was brought up on the IETF SIP mailing list http://bugs.sipit.net/show_bug.cgi?id=760 I haven't had the time to look into it though. /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] URI transport parameter
On Mon, Nov 06, 2006 at 11:03:01AM +0100, Fredrik Thulin wrote: > > What if you type in an address of "sip:[EMAIL PROTECTED];transport=udp" in > your user agent, but example.org has NAPTR/SRV records giving precedence > to TCP? When your user agent sends the request to your YXA proxy > (presumably using UDP), what transport should the YXA server use after > it resolves the NAPTR/SRV records of example.org and sees that the UAC > has requested one protocol, but example.org prefers to be contacted > using another? > > I'll have to think about that at least over lunch. > > /Fredrik > I assume that the user agent is configured with a pre-set route set (AKA outbound proxy), otherwise the user agent should send the request directly to the example.org server. 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. Btw, when using NAPTR you should select the most preferred transport protocol, and not use all. RFC 3263 4.1 The NAPTR processing as described in RFC 2915 will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. Mikael ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
Re: [Yxa-devel] URI transport parameter
Mikael Magnusson <[EMAIL PROTECTED]> wrote: > Hi, > > the transport parameter is only used by sipdst:url_to_sipdst if the > host contains a numeric IP address, but according to RFC 3263 section > 4.1 it should be used for other addresses as well. Right, good catch. I started making that change, but stumbled onto a question. What if you type in an address of "sip:[EMAIL PROTECTED];transport=udp" in your user agent, but example.org has NAPTR/SRV records giving precedence to TCP? When your user agent sends the request to your YXA proxy (presumably using UDP), what transport should the YXA server use after it resolves the NAPTR/SRV records of example.org and sees that the UAC has requested one protocol, but example.org prefers to be contacted using another? I'll have to think about that at least over lunch. /Fredrik ___ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel
