Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Dec 2000 11:35:07 -0500

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Friday, December 01, 2000 5:12 AM
> To: Fairlie-Cuninghame, Robert; [email-masked]
> Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements
> 
> Still, I'm not convinced; but also I'm not that passionate.
> Either way is a reasonable solution (with the proxy-does-the-work
> being slightly more robust), so whatever the concensus is, eh?
> (Although it does look like everybody else has given up, so we
> might have to toss a coin... (:&)

Well, not given up, by I have a job besides reading and answering mail on
the sip ml, and keeping up these days on a daily basis is a full time job.

That said, this enormous thread has run all over the place. I think there is
a fair amount of agreement, with just a little bit of disagreement.

My perception of the consensus is:

1. the current bis mechanism of having the UA mangle the record-route is
gone.
2. in the forward direction, the proxy inserts a URL which must route to
itself. I further believe that the consensus is that this should be a SIP
URL. I'll say a bit more on that in a moment.
3. UAS copies RR in its entirety into response.
4. proxy MAY modify the RR in the response
5. UAC build the route as described in rfc2543, UAS builds the route by
putting the Contact on the end of the RR set.
6. The RR inserted is largely at the discretion of the proxy, subject to
(2).

There was some debate about whether the RR URL could be a SIP URL. I think
it should be - primarily because it simplifies operation, is backwards
compatible, and guaranteed to interoperate. Since no other URL type is
guaranteed to be supported, inserting anything but a SIP URL may result in
an interop problem. In any case, the primary purpose of the URL in the RR
(and indeed, the URL in Contact header in INVITE and 200 OK as well) is
identifying a specific entity at a specific next hop server. Its purpose is
therefore to represent an address more than a name, and a SIP URL is ideal
here.

Now, the issues of contention remain:

1. should modification of the URL in the RR in the response be MAY or SHOULD
or MUST
2. Robert's proposed Contact/RR mangling to deal with UAs that don't insert
Contact

Regarding 1:

I think there are lots of advantages to being able to insert a different URL
into the response; the transport can be different on each side, for example,
which cannot be done if only a single URL is inserted. It also allows for
stateless determination of call direction in a proxy. It allows for services
to be applied to a request which can operate independently of whether its an
initial (thus without Route, using the R-URI alone to identify the target)
or subsequent (in which case the Request URI, From/To and possibly other
headers are needed) request. It also works in proxies which don't actually
pop the top Route and use it, but rather do something and then forward the
request to a specific next hop (this can be used to break a single proxy
into a number of smaller ones that appear as a single proxy to the outside).
But, all of that points to MAY, not SHOULD.

However, I would argue that, in practice, proxy users will find increasing
numbers of use cases where the request URI needs to be something meaningful.
Specifically, any time a proxy actually wants to apply any kind of
processing on the request beyond pop-the-top-route-and-forward. As a result,
this feature is likely to be a MUST in practice.

The only argument I can make for the SHOULD requirement in the spec is that
it makes the protocol less brittle; correct operation no longer depends on
Route processing being done correctly at every single proxy. 

So, I'm willing to compromise here, and keep this a MAY in the spec, so long
as the functionality is described, along with some of the cases where it
will find useful application.

Regarding 2:

This seems a very orthogonal issue. I don't really like it, because I don't
think it will be needed in practice, and it makes assumptions about
processing at previous hops. Specifically, it assumes that the non-existence
of the Contact header implies an older client, and it assumes that the
To/From field won't successfully get a call routed properly. I can imagine a
SIP security proxy that removes all internal Via/Contact/RR headers, and
inserts a single RR header pointing to itself. The next hop proxy might then
insert a Contact header, making things very confusing.

I also don't think it will be needed in practice, since making Contact
mandatory was one of the first things we added to bis. I think that most UA
devices do insert Contact these days. In any case, I hate to litter a spec
with hacks designed to support features that are only potentially useful
during a transition period (which may already be over).

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 03 Dec 2000 12:13:06 -0500

Jonathan Rosenberg wrote:

> 1. the current bis mechanism of having the UA mangle the record-route is

Are you talking about the UAS creating routes in the callee-to-caller
direction or what other mangling?

> putting the Contact on the end of the RR set.

Let's see if I got this right. Let's assume the following example:

alice@from calls bob@yahoo, who is really bob@acme, which translates to
[email-masked], which becomes [email-masked]

All entities (yahoo, acme, and sales.acme) RR. Thus, we have on the
forward direction when the request reaches bob, the 200 OK becomes:

Contact: sip:[email-masked]
Record-Route: sip:[email-masked],
 sip:bob@acme,
 sip:bob@yahoo

Alice now sends subsequent requests as

Route: sip:bob@yahoo, sip:bob@acme, sip:[email-masked],
sip:[email-masked]
Contact: alice@from

If Bob wants to send requests to Alice, are we still at the old
mechanism or is the assumption that Bob inserts

Route: sip:[email-masked], sip:bob@acme, sip:bob@yahoo

and leaves it up to the proxy to figure out that this request is going
in the reverse direction? (It only matters for yahoo in this example.)

> 6. The RR inserted is largely at the discretion of the proxy, subject to

Thus, the requirement for maddr insertion disappears, presumably.

> therefore to represent an address more than a name, and a SIP URL is ideal

To elaborate: all other URL types, say, H.323 or tel, are by definition
meant to route to any number of destinations. By definition, this
determination should be made when first routing the request. RR is meant
to make sure that requests get back to the same place, to update state,
for example. Thus, using non-SIP URLs directly contradicts this goal. It
is also far from clear why this is useful, given that all other URLs can
be translated into a unique token at the proxy that originally received
the non-SIP URL.

> 1. should modification of the URL in the RR in the response be MAY or SHOULD

I assume you mean that the Record-Route in the 200 is mangled by the
original proxy that stuck it there in the first place?

> will find useful application.

SHOULD is, in any event, a weasle answer, since nobody else can rely on
this behavior. 

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Sean Olson <[email-masked]>
Date: Sun, 03 Dec 2000 12:34:41 +0100

Just my two cents worth on the use of non-SIP URLs in the RR.
(I think I was the only person arguing for this :)

> be translated into a unique token at the proxy that originally received

Please correct me if I am wrong, but one of the goals of the RR was
to carry state/context information in the RR itself(?) I have no problem
with one component of the RR being a SIP URL which uniquely routes to the
given proxy (in the appropriate direction). What I wanted was a way to preserve
the Request-URI from the original request in the RR. As suggested, this can
be saved in the proxy and referenced by a unique token. But I believe there
was a desire for RR to work for "stateless" proxies as well. If this is not
a requirement, then I'm happy with the solution as is. If this is a requirement,
then we need a way to carry this state or Request-URI in the RR.

On a slightly related note, can I assume that the SIP URL in the RR will be
inserted as is in future requests, including any (possibly unknown) parameters?
And how will maddr and transport be handled?

thanks
/sean

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 03 Dec 2000 13:54:19 -0500

Sean Olson wrote:

> then we need a way to carry this state or Request-URI in the RR.

I think that the URL should be copied as-is, including all parameters,
known or otherwise. I believe that's what the current draft says, at
least implicitly. The only question is whether items marked as "not
allowed" in a request-URI should still be copied. While I wouldn't call
the protocol police on somebody who didn't "sanitize" the request URI, I
don't think it would be a good idea to rely on that. The only two
parameters not allowed in Request-URIs are method and headers.

Since any Record-Route element is copied to Route, I'd assume that
something like

Record-Route: <sip:proxy.com> ;original-url="tel:12345"

would be carried along. However, as, I believe, has been discussed
previously, this will not be visible to the receiving party since the
Route entry will have been stripped upstream.

If you want to encapsulate state, you have to stick it into the
request-URI, as in

Record-Route: <sip:proxy.com;original-url=something>

or use some other appropriate (State) mechanisms. To avoid escaping
nightmares and since the user part is strictly a local matter, it may be
simplest to just take the state tokens you need, put them in a base-64
encoded string and use that as the user part, as in

[email-masked]

for

alice;tel=12345

I'm not recommending this except as an implementation hack in case all
else fails. At some point, I'd rather have people do this then increase
the amount of base-protocol complexity and interoperability cases to be
tested.

---

From: Billy Biggs <[email-masked]>
Date: Mon, 4 Dec 2000 01:00:51 -0600

Henning G. Schulzrinne ([email-masked]):

> alice@from calls bob@yahoo, who is really bob@acme, which translates
> to [email-masked], which becomes [email-masked]
> 

  In my perfect SIP world, the 200 OK response is:

  Contact: sip:[email-masked]
  Record-Route: sip:sales.acme, sip:acme, sip:yahoo

  Alice now sends subsequent requests as:

  Route: sip:yahoo, sip:acme, sip:sales.acme, sip:[email-masked]
  Contact: alice@alices-contact

  And Bob's requests look like:

  Route: sip:sales.acme, sip:acme, sip:yahoo, sip:alice@alices-contact
  Contact: sip:[email-masked]

  Proxies insert an address which represents that proxy, irrelevant of
the original request-URI (most proxies won't need to remember it).
All call state information is in the To/From/Call-ID (leg identification
+ request direction).  Special state keys can also be placed in the
username or as helpful parameters.

  Why should the spec specify any behavior besides placing an address
which maps back to the correct proxy?

  I'm also not for anything stronger than MAY regarding changing the
Record-Route in the response on the way back, specifically because I see
proxies using an RR address of 'sip:proxy'.

-- 
Billy Biggs, 3Com               Email: [email-masked]
http://www.div8.net/billy/      Phone: [email-masked]