Subject: Re: Request-URI

From: Sean Olson <[email-masked]>
Date: Fri, 2 Jul 1999 10:16:30 -0500 (CDT)

> Hi,
> 
> Section 1.4.2 of the SIP RFC:
> "If the Request-URI specifies a protocol (TCP or UDP), the client..."
> 
> At the end of the section 2, the transport-param (UDP or TCP) seems to
> be forbidden for a Req-URI ( table 2 ).
> 
> How's that?
> 

It SEEMS like a good idea to allow the transport-param in the Request-URI
as this information is allowed in the Contact: header of a REGISTER. This
of course allows a UAS to specify that it only provides UDP or only TCP
or has a definite preference for one of the two. The problem as I see it
is the propagation of this information through a chain of proxies, particularly
if one or more of those proxies has a different preference than the UAS
you are ultimately trying to contact. The transport-param really should only
apply to the last proxy in the chain, but how do you specify this? Also,
should a proxy be allowed to re-write the transport-param? (It has to)
(The transport-param is a hop-by-hop indication(?), but the Contact: info is
 really only a last hop indication(?))

For example, consider a UAS that only supports TCP, located behind a 
firewall proxy that only supports UDP. What should the Request-URI look like?
For that matter, what should the Contact: look like in the registration?

> Regards,
> 
> Gonzalo
> -- 
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 31 18
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland
> 

-----------------------------------------------------------------
Sean Olson            E-mail: [email-masked]
Ericsson Inc.         Voice: (972) 583-5472 
                      FAX: (972) 669-0154

---

From: "Adam B. Roach" <[email-masked]>
Date: Fri, 2 Jul 1999 19:04:24 -0500 (CDT)

>firewall proxy that only supports UDP. What should the Request-URI look like?

Actually, I think this is fairly well defined; the request URI 
would be of the form:
sip:[email-masked];transport=tcp

And you'd configure your firewall proxy to be, for example:
sip:firewall.localdomain.com;transport=udp

If there are a string of proxies (or redirect servers or any
combination of the two), each URI could potentially have a
transport parameter associated with it.

For example, let's assume that your firewall proxy is configured
in your client as "sip:firewall.localdomain.com;transport=udp".
You're trying to call Bob Smith, who has given you his
preferred address as "sip:[email-masked];transport=udp".

1) uac -> r1 (localdomain.com), using UDP
INVITE sip:[email-masked];transport=udp

2) r1 -> uac, using UDP
302 Temporarily Moved
Contact: sip:[email-masked];transport=tcp

3) uac -> p1 (firewall.localdomain.com), using UDP
INVITE sip:[email-masked];transport=tcp

4) p1 -> p2 (sip.tpc.int), using TCP
INVITE sip:[email-masked];transport=tcp

In this example, I'm going to make p2 a registar that has
been instructed to proxy calls to Bob Smith.  Further, Bob
has registered with p2 as "sip:[email-masked];transport=udp".

5) p2 -> uas (dialup01234.isp.net), using UDP
INVITE sip:[email-masked];transport=udp

Each hop in the chain is identified by its own URI (whether
through configuration, as in the case of a firewall proxy, or 
from a lookup, as in the registrar/proxy example). Each of these
URIs may have a transport attribute associated with it, which 
identifies the transport to be used *for* *that* *hop*, not end-to-end.
Note that this is not necessarily going to align with the 
Request-URI in that same request (firewall proxies are an example;
see number 3, above).

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 07 Jul 1999 23:18:15 -0400

Adam B. Roach wrote:

> INVITE sip:[email-masked];transport=udp

For 4) and 5), I don't believe the transport parameter is needed. The
server that the request is being sent to is the result of a lookup of
the URI in the request URI, and the transport being used was the one
that was in the URI. Thus, there is no need for indicating the
transport; the request is being sent with that transport anyway.

As a general rule, if the server that the request is being sent to is
the one corresponding to the request URI, nearly all of the parameters
are not needed - port, transport, maddr, ttl - since these are being
used for sending the request itself. If, however, the server the request
is being sent to is NOT the one in the URI, these parameters should
appear in the request URI if they were specified. This allows that
server to use the parameters to proxy the request correctly.

For example, if A has the URI sip:user@domain:5000;transport=tcp, and it
sends the request to the host determined through a lookup of "domain",
the result is:

INVITE sip:user@host SIP/2.0

sent to port 5000 using TCP.

If, however, A is configured with some local proxy:

INVITE sip:user@host:5000;transport=tcp SIP/2.0

sent to the local proxy, on whatever port/transport A has been
configured to use. The proxy, in turn, sends a request:

INVITE sip:user@host SIP/2.0

now to port 5000 of the proxy for "domain" using TCP.

Note that nothing is wrong with Adam's suggestion - you could put the
transport parameters in the first INVITE above, but it doesn't do any
real good. The proxy for "domain" will see that the request URI is for
its own domain, and perform some location function, translating the URI
to something else altogether - sip:[email-masked], for example,
and then send that using UDP/TCP or whatever according to configuration
or the procedures for SRV lookup in RFC2543.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen