Subject: [SIP] New Section 6.34 (was: Record-Route consensus)

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 22 Nov 2000 17:45:24 -0000

Okay, here's a proposal for a new Section 6.34.  Hopefully, this
is as backwardly-compatible (to 2543) as we could possibly be
(that is, it should work with a 2543 proxy, and it even has a
good chance of working with a 2543 UA, if it was the one calling).

Also, this should solve using Record-Route when a proxy receives
a request with a non-SIP Request-URI.  The changes are basically
now that a proxy is free to put just about any URI into a
Record-Route value, as long as it's a UDP SIP URL; and the called
UA no-longer does the nasty mangling when copying into the Route.

Anyway, without further ado...

6.34 Record-Route

6.34.1 Operation

 The Record-Route request and response header field is added to a
request by any proxy that insists on being in the path of subsequent
requests for the same call leg.  A proxy SHOULD add it to any request
for robustness, but a request route, once established, persists until
the end of the call leg, regardless of whether the Record-Route header
is present in subsequent requests.

    Some proxies, such as those controlling firewalls or in an
    automatic call distribution (ACD) system, need to maintain call
    state and thus need to receive any BYE, re-INVITE and ACK packets
    for the call.

 Each Record-Route header field contains a globally reachable SIP URL
that identifies a proxy server.  Any proxy that wishes to remain in
the signalling path of a call leg adds its own SIP URL to the
beginning of the list of these fields.  This SIP URL MUST represent an
address that is reachable via UDP.  Requests between both user agents
involved in the call leg, in either direction, traverse this route.

    Inclusion of, say, a TCP transport parameter may prevent a UA that
    supports only UDP but reached the proxy inserting the Record-Route
    via another proxy from reaching this proxy.

 The UAS copies the Record-Route request header field unchanged into
the response.  (Record-Route is only relevant for 2xx responses and
responses where the server can expect the client to retry for the same
Call-ID, as in 401 (Unauthorized) or 484 (Address Incomplete).)

 *** Should we remove this bit about 401 and 484?  It makes things
     more complicated, and also what if a proxy has collected a load
     of WWW-Authenticate and Proxy-Authenticate headers into a
     401 (Section 12.4 of bis2) -- the Record-Route could be arbitrary.

6.34.2 Construction of Route header

 If a UAC finds a list of Record-Route header fields in a final
response to the initial request in a call leg, it copies this list
into Route header fields of all subsequent requests within the same
call leg, reversing the order of fields, so that the first entry is
the server closest to the UAC.

 *** I haven't said initial INVITE here, since wasn't there some talk about
     abstracting it for, say SUBSCRIBE/NOTIFY purposes?

 If a UAS finds a list of Record-Route header fields in the initial
request in a call leg, it copies this list, maintaining its ordering,
into the Route header fields of all subsequent requests within the
same call leg.

 In either case, the UA MUST copy all SIP URLs verbatim.

    This allows a proxy to add a SIP URL parameter indicating a
    request's original Request-URI, for instance.

 If the request/response featured a Contact header field, the UA Contact
header value is appended to the list of Route header fields.  If this
Contact header value is found to have changed in a subsequent request
or response, then the new value MUST then be used.  Note that the same
is not true of changes to list of Record-Route header values.

 *** If no Contact, should add the From?

6.34.3 Request Destination

If a client finds a list of Route header fields in a request, it
SHOULD send the request to the first SIP URL in the list.  A client
MAY forward the request to a designated proxy instead, for example, if
it lacks DNS resolution capability.  If a client uses the first Route
entry to route the request, it removes it.

6.34.4 Syntax

The Record-Route header field has the following syntax:

    Record-Route = "Record-Route" ":" 1#(name-addr *(";" rr-param))
        rr-param = generic-param

6.34.5 Example

Example for a request where the proxy servers at vanity-domain.com,
ieee.org, and sunnydale-high.edu, in that order, insist on being part
of subsequent request paths:

    Record-Route: <sip:[email-masked]>
      <sip:ieee.org;uri=sip:[email-masked]>
      <sip:sip.vanity-domain.com:6000;uri=tel:+1-972-555-2222>

 *** I took the liberty of making the example Record-Route slightly
     more exotic. &;)

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 22 Nov 2000 20:01:42 -0800

Hi Jonathan,

That is a very interesting suggestion. I like the motivation to have the
Route's different in each direction.

You said that in one direction the Route was

Route: [email-masked]

and in the other direction

Route: [email-masked]

Only the proxy understands the significance of A and B so is there any point
in proscribing that it must be of the above form, for instance, can you see
any disadvantages of:

Route: proxy.blah.com;rstate=A 

and 

Route: proxy.blah.com;rstate=B

If the answer is that you would like the base URL to be different for
robustness, ok that's fine. In that case A and B could just as easily be a
unique token, eg "1" & "2" or literally the characters "A" and "B"
(regardless of the request URI). Should we just leave it up to the proxy ?
Does the user part need to be present at all? 

Additionally, if the proxy is keeping full call state, eg based on unique
Call-Id. Is it REQUIRED to mess with the Record-Route in the response.
Otherwise, adding a simple

Record-Route: proxy.blah.com

would be sufficient. [If the request spirals it will need to add something
different the second time but it still doesn't need to be different in each
direction.] What I am getting at is are you trying to make this a
requirement for the sake of protocol "invariant-ness" or merely as a helpful
recommendation for proxies not wanting to keep full state. ie, SHOULD or
MUST

Regardless of the above handling by the proxies, it seems that we have
reached a consensus that the UAS should no longer mangle the reverse Route
which I think is an important point. I believe it will be a lot easier to
change how proxies handle the Record-Route processing than the behaviour of
the UA's already out there - so the sooner the UA behaviour is settled the
better. It also makes the UA behaviour a lot simpler - which is always a
good thing. Agreed?

Regards,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, November 23, 2000 7:12 AM
> To: 'Billy Biggs'; Jonathan Rosenberg
> Cc: Jo Hornsby; [email-masked]; [email-masked]
> Subject: RE: [SIP] New Section 6.34 (was: Record-Route consensus)
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Billy Biggs [mailto:[email-masked]]
> > Sent: Wednesday, November 22, 2000 6:10 PM
> > To: Jonathan Rosenberg
> > Cc: Jo Hornsby; [email-masked]; [email-masked]
> > Subject: Re: [SIP] New Section 6.34 (was: Record-Route consensus)
> > 
> > 
> > Jonathan Rosenberg ([email-masked]):
> > 
> > > 5. (this one is my own) The request URI should refer to 
> the resource
> > > for whom the message is destined
> > > 
> > > The solutions proposed are either to have the UAS and UAC 
> construct
> > > the Route differently (as is done in the current bis), else 
> > Jo's text
> > > here where this information is carried somehow as 
> > parameters. I think
> > > this is a big hack, and quite a pain. When a proxy receives a
> > > re-INVITE, it will have a hard time knowing which direction the
> > > re-INVITE is going, and consequently, which of the pieces 
> of info to
> > > extract for processing purposes.
> > 
> > 
> >   The proxy should look at the To and the From to tell direction,
> > instead of doing this ugly hack! [1]
> > 
> >   The only note then is that if a UA calls itself through a
> > Record-Route'ing outbound proxy, then the tags it inserts had 
> > better be
> > different.  [I think you've heard that argument before!]
> > 
> > 
> >   Still, bis shouldn't talk about any of this.  Keep the spec really
> > simple, and let proxies which need to keep state figure out how to
> > record-route to their advantage.  Jo's text is pretty much on 
> > the mark.
> > 
> > 
> >  [1]  Or, it can always just look at which address is at the 
> > end of the
> >       Route...  Regardless, your suggestion is an ugly hack.
> 
> Billy, I prefer to hold list discussions based on technical 
> issues rather
> than name calling.
> 
> Proxies route based on request URIs. I'll say it again. 
> Proxies route based
> on request URIs. As such, it is really important that the request URI,
> without needing to examine the To/From, by itself, indicate 
> the resource to
> whom the request is targeted. 
> 
> -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
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 23 Nov 2000 16:27:23 -0500

> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Thursday, November 23, 2000 10:21 AM
> To: Jonathan Rosenberg
> Cc: 'Jo Hornsby'; [email-masked]; [email-masked];
> [email-masked]
> Like Robert I struggle with this RR URI which "identifies the
> [caller/callee] as a resource on this proxy". In the typical case only
> one of the two parties would be known in any meaningful way to the
> proxy.  The proxy record-routes using its own SIP URL and can derive a
> user name from the caller/callee but they won't necessraily mean
> anything to it, and it wouldn't necessarily be able to route 
> messages on
> it (and it won't have to - that's what the Route is for). 
> This means [5]
> isn't really satisfied anyway.

My initial posting was not sufficiently detailed to explain this, so let me
clarify.

The URL inserted into the request must be something that (1) given the
client follows the server location process in draft-ietf-sip-srv-00, causes
the URL to be resolved to an address/port on the proxy, and (2) is a URL
that, if received by the proxy, the routing logic in the proxy would cause
the request to be forwarded to the Contact/From address of the calling
party. Similarly, the URL in the response must be something that (1) routes
to the proxy, and (2) is a URL whose routing logic in the proxy would cause
the request to be forwarded to the Contact/From address of the called party.

Since we don't dictate routing behavior, so too would the format of these
URLs not be specified. So, if we assume the caller is [email-masked], and
the called party is [email-masked], one choice for the URL pair (request,
response) is:

([email-masked];maddr=proxy, [email-masked];maddr=proxy)

this tuple results in the same Route set getting constructed as gets
constructed by the current bis mechanism. The tuple satisfies the first
mandated property since the maddr causes the routing to go to the proxy. The
second is satisfied for any proxy that always forwards requests not in its
domain to the domain the R-URI, and for the originating.com proxy, knows how
to find A, and for terminating, knows how to find B.

Now, another way to structure the pair, that the terminating proxy could
use, is:

([email-masked], [email-masked])

assuming its routing policy was that if the domain was its own, and the user
in the R-URI is unknown, the R-URI is URL-decoded. If it contains an @, the
resulting URL is used as the new request URI.

Now, consider the case of a proxy that has some kind of call state or
something, and a spiral comes through it, and it needs to differentiate each
pass through the spiral. In this case, the two tuples it could use are:

([email-masked];maddr=proxy;sessionid=76599,
[email-masked];maddr=proxy;sessionid=76599)

([email-masked];maddr=proxy;sessionid=876,
[email-masked];maddr=proxy;sessionid=876)

This satisfies that problem raised on the list with state and spirals.

>Otherwise, adding a simple

I think yes, since otherwise we won't achieve this property of the request
URI referring to a resource that would cause the request to be routed to the
appropriate party.

Now, things won't break if the proxies don't do this, but they become more
brittle, and various other subtle things might happen down the road. I had
come up with some other scenario where this property was needed, but don't
recall when it was.

-Jonathan R.

---

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 24 Nov 2000 07:05:56 -0800

> 
> > So how does that help with the desired invariant property? I
> > beleive using parameters would be better.
> 
> I don't think it matters how the URI is formed, as typically
> it's only going to make sense to the proxy that inserted it
> (unless we come up with a BCP, or sommat).
> 
> I think when I talk about this invariant, I don't necessarily
> mean that the Request-URI along the entire route would be
> routable by an arbitrary proxy; what I mean is that the
> Request-URI would be routable at the salient proxy.
> 
> I think what Jonathan didn't like -- and I wasn't happy about
> it, either -- was that in the reverse direction, the Request-URI
> could in no way ever have been useful in finding the calling
> UA (save the case that the calling and called UA were the same,
> perhaps).  With the sorts of things being proposed now --
> having a different URI on request and response, or somehow
> embedding the caller, say -- this is no longer the case.  Sure,
> it's likely that only the proxy that inserted the URI will
> understand it, but that's in no way atypical, and I feel
> still satisfies the invariant.

I also like the idea. How about we express the invariant in the most simple
way possible: the user portion of the Record-Route indicates the direction
to the proxy (but it does not need to [necessarily] represent the original
Request-URI/Contact - allowing the proxy to rely on such "slightly mangled
original-uri" information, in my mind, is making things MORE brittle not
less [and complicated] )? 

Anything else should be left up to the internal implementation of the proxy.
eg including route state, original uri (if necessary), spiral tag (which
should be recommended), etc. The ammount of information included in the
Record-Route may be influenced by the ammount of information stored for the
call and how routing is performed (eg the Request-URI may not actually be
helpful in identifying the same routing destination for load-sharing or
time-dependent routes).

> > As for maddr handling: If the proxy is required to add the rr-uri 
> > parameter, then I think the proxy must also replace any maddr with
> > a "rr-maddr" parameter so that the outgoning request-URI is
> > faithfully recreated.
> 
> I'm not sure why this is needed?  Couldn't we just do something
> like:

Sorry, you're right I was getting confused - its not needed. 

> > Once again, all we can do is provide a recommendation for proxies
> > not want to keep full state. So all we have to specify in 
> the spec is 
> > characteristics of what the base user@host is, right?
> 
> I don't think we even need a user.
> 
I don't think it would hurt having a user - it makes the invariant easier to
express (as above). I don't know whether requiring a user part should be a
SHOULD or MUST but I feel a SHOULD is more appropriate.

[Boy, Jonathan's going to have a few emails waiting for him tomorrow.]

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 24 Nov 2000 07:14:22 -0800

> 
> > > > However, the parameters
> > > > _are_ being treated as URL parameters in the Request-URI so the
> 
> I think there's still a need to distinguish between Record-Route
> parameters (that is, rr-params in section 6.34 of bis02) and the
> parameters that a proxy adds to the SIP URL that it places in
> a Record-Route value.  Record-Route params might still prove to
> be useful; they could be used so that a proxy can identify the
> Record-Route entry that it added, for instance.
> 
I agree. They should be distinguished and that's a very good suggestion for
the using the former (Record-Route URL parameters?). What do we call the
latter? Record-Route Request-URI parameters ?
As for any complex escaping schemes, I think that we should be aiming to
make Record-Route/Route as simple as possible - its complicated enough
already. :) [Thank god we can now at least get rid of route mangling in the
UA.]

Robert.

---

From: Billy Biggs <[email-masked]>
Date: Fri, 24 Nov 2000 14:33:46 -0600

>> [caller/callee] as a resource on this proxy". In the typical case
>> only one of the two parties would be known in any meaningful way to
>> the proxy. [...]
>
> My initial posting was not sufficiently detailed to explain this, so
> let me clarify.
>
> The URL inserted into the request must be something that
> (1) given the client follows the server location process in
>     draft-ietf-sip-srv-00, causes the URL to be resolved to an
>     address/port on the proxy, and
> (2) is a URL that, if received by the proxy, the routing logic in the
>     proxy would cause the request to be forwarded to the Contact/From
>     address of the calling party.
>
> Similarly, the URL in the response must
> be something that
> (1) routes to the proxy, and
> (2) is a URL whose routing logic in the proxy would cause the request
>     to be forwarded to the Contact/From address of the called party.

  I'm ok with (1) on both of these.  (1) should be the same in both
directions, and the proxy must know this address itself.  If (1) isn't
the same in each direction, the proxy can insert two record-routes.

  I don't understand the reasoning behind (2).  If the message has a
Route, you do NOT want the routing logic in the proxy to be applied, as
this may have changed since the Route was set.  The request MUST be
routed according to the Route.

  Proxies which maintain state can of course put some magic parameter,
but I don't see why this must be unique in each direction.  However, if
some proxy requires it, then it too can put in two Record-Routes, and
then have enough smarts to remove both.

  I belive that all uses for Record-Route can be solved by using:

  <sip:proxy;state=cookie>

  With the exception of firewall proxies, where it is sufficient to use:

  <sip:firewall.proxy>

  If some middle-man snarfs the message, that's ok, because routing it
to the request-URI will get it to the correct destination: the proxy,
and that proxy can surely identify the message as being for it.  From
there, the proxy MUST use the Route to route it.

  Looking at your tuples:

  The only advantage I see is redundancy.  If proxy is down, then maybe
some clients might send the request to the rest of the address.
However, this will avoid all of the other proxies in the Route.  A
better idea would be for a smart node to instead drop this entry from
the Route and try the next URI.

  If this is purely information for the proxy to know, then fine
they're free to do it, but I don't see any reason why this needs to be
mentioned in the spec.  Seems like a special (and complicated) case to
me.  How is <sip:firewall.proxy> more brittle?  Trying to implement the
tuple scheme: finding an algorithm to copy the request-URI and add in an
maddr of the proxy, finding your record-route in the response and
mangling it, seems awfully brittle in itself.

  I have been told that using the maddr technique helps protect against
UAs which don't insert a Contact.  However, I can't come up with a
scenario, and now Contact is mandatory for INVITEs and 200-class
responses.

>> Additionally, if the proxy is keeping full call state, eg based on
>> unique Call-Id. Is it REQUIRED to mess with the Record-Route in the
>> response.  Otherwise, adding a simple
>
> I think yes, since otherwise we won't achieve this property of the
> request URI referring to a resource that would cause the request to be
> routed to the appropriate party.

  The appropriate party is the proxy.  After that, the appropriate party
is spelled out clearly by the Route.

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 27 Nov 2000 21:34:19 -0800

Hi Billy, 

>   Some brief comments:
 Great.
 
> > Take the tel case: you are not interested in routing to the tel: of
> > the final destintion but rather in routing to the next proxy that
> > wanted to remain in the path - through a globally udp-reachable
> > address. For instance, UAC->P1->P2->P3->P4->UAS. If P3 Record-Routes
> > with a some URL scheme scheme only known by adacent 
> proxyies P2 and P4
> > then the call will fail because either the UAC or P1 must 
> also be able
> > to route to P3 based on the Route.
> 
>   If P2 and P4 Record-Route then this isn't a problem.
> 
>   Allowing unknown URI schemes in the RR/Contact/ReqURI is cheap.
> However, they only work in a strictly engineered private network.

I disagree that it is cheap. Sure its easy to just say "allow non-SIP URL's
in Record-ROutes" but in my mind it adds a lot of extra brittleness and
conceptual complexity that is not useful in anything _but_ strictly
engineered private networks. If the network is a strictly engineered private
network then surely the proxies can come up with a method of representing
the required information in a SIP URL? 

> 
> > IMO Request-URI's are different due to that fact that the 
> Request-URI
> > can be translated as it traverses a network - so you only 
> have to know
> > whether or not an adjacent proxy/UA supports a certain (non-SIP) URL
> > scheme. This is NOT TRUE after the initial INVITE and you also no
> > longer want to do network-independent routing. 
> 
>   There might be a transparent SIP proxy between you and this
> destination which will snarf the message, at which point you lose the
> ability to route based on request-URI.  This is unacceptable.

Ok, your right but I still purtain that this is different to placing a
non-SIP URL in a Route header. With the Request-URI, once the request hits a
proxy that converts the tel: URL to a sip: Request-URI then all further
proxies don't need to understand tel URL's (which is a feasible
requirement). If a proxy inserts a tel URL then all UA'a and proxies in the
path must potentially understand how to route tel URL's - which is not
feasible. 

As you argue, proxies could collude to "buffer" non-SIP Route URL's but will
probably result in assymetic Routes and all sorts of other trouble for what
gain?

> 
> > As an aside, we were discussing earlier that about route parameters
> > and angle brackets. A couple of peopel agreed that for
> > 
> > Record-Route: <url>;rr-param
> > 
> > 
> 
>   You are correct that rr-params don't get copied into the 
> request-URI.
> This is why placing routing information in rr-params is broken.

We are not suggesting this. We are saying that implementation specific
information (I think calling it routing information is confusing) can be
placed into the URL parameters -not header parameters.
> 
>   This does not mean that rr-params are useless.  They may be 
> useful for
> extensions which require special behavior from the hop before.

We agree on this.
> 
>   Note that parameters aren't standard across URI schemes.  
> As such, we
> can't define, say, an "maddr" parameter and expect it to have
> significance in a tel URI.

EXACTLY!! You don't have this problem if you don't try to put non-SIP URL's
in the Route header  Why should any other SIP entity have to handle this
information? Other entities only have to ensure that the message is routed
to the proxy. Are saying that this private network has no concepts of
routing via hostnames or addresses?

Regards, 

Robert.

---

From: Bertil Engelholm <[email-masked]>
Date: Tue, 28 Nov 2000 09:28:38 +0100

"Fairlie-Cuninghame, Robert" wrote:
> 
> Hi guys,
> 
> So to patch that problem a raddr parameter is suggested - that all UA's and
> proxies must understand. However, the raddr must still specify a globally
> udp-reachable address for things to work (otherwise you run into the same
> problem). So what's the point? Just KISS and stick with SIP URL's. I think
> the simpler something is, the more likely it will be to work across
> everyone's SIP devices - and this is somethign you want to work.
> 

Well the reason for the raddr parameter is the same as the
maddr parameter for SIP-URL. But having it as a RR parameter
makes it more general and independent of type of URI.
If you have a pool of machines building up a big SIP server 
you may want to make shure every new request for a certain
call-leg ends up on a specific machine in the pool (where
you have the states for this specific call-leg). This
is what I understand maddr was for. But since maddr only
exists for SIP-URL, how to do it for other types of URIs ?

This is the reason why I suggested the raddr parameter.
With the raddr parameter a server can specify which machine
it wants further requests to be sent to regardless of what
type of URI it has put into record-route. That was the idea
anyway. If people are happy with that you only can have
SIP-URLs in record-route then the raddr is not needed.
Personally I see a risk that some new type of URI pops
up in the future that SIP also needs to support in RR.

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 28 Nov 2000 00:58:26 -0800

Hi Bertil,
> exists for SIP-URL, how to do it for other types of URIs ?

Are you suggesting something of the form:

Record-Route: <tel:911>;raddr=emergency.sd.com

then the Request-URI will become simply tel:911 which sees potentially
brittle to me. 

Something of the form 

Record-Route: <sip:[email-masked];blah2=blah3> 

where blah and blah2 represent implementation specific fields possibly
encoding tel:911 [or better yet, something more useful to the proxy] will
still always be routed to the proxy regardless of what happens in between. 
The field blah and blah2 only have significance to the proxy and hence don't
need to be mandated/examined/interpreted/understood by anyone but the proxy.

In this context, the SIP URL is essentially only describing the next hop
address - much like the Via field. I haven't heard requests (yet) to put tel
URL's into the Via fields becuase it is unneccessary - all you need is the
address and port - all other information is significant only to the
generating proxy and hence it can encode what it wants, right ?

Robert.