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

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 1 Dec 2000 09:37:11 -0000

> > I don't think that proxies should start second-guessing UAS.
> > I would say that the simplest thing is just to say that when the
> > UA is building the Route header list, it should append the
> > Contact, if present; failing that, the From.
> > 
> > Really old UAs might lose, but they were always going to do
> > that, anyway[0].
> > 
> What about in the other direction? The UAC will need to add a
> Record-Route for the _original_ Request-URI - which may in fact
> be entirely unhelpful.

I'm not following you here.  I was suggesting that the UA --
i.e., UAC and UAS -- append the From header if the Contact
header is not present.

Actually, if I say that the calling UA can append the original
Request-URI instead of the From, then isn't this identical to
what you're saying, except the UAs are doing it instead of the
proxies?

> If the proxy were to add the extra
> Record-Route I think that is much safer as it knows what its
> own behaviour will be when it receives the request..

Indeed.  However, I think it's slightly dangerous for a proxy
to think that it knows better than a UA.

> I guess, I was also trying to stick with the existing RFC2543
> and bis UA behaviour (minus route mangling). Ie, the UA doesn't
> add an extra Route-Header for the original From or Request-URI
> - its only added if there is a Contact (which I think is a good
> thing !!).
> 
> I think we can do better than saying RFC2543 doesn't work. 

It's not the case that it doesn't work.  It's just there's
a failure case where the From is not directly routable.
If I use a SIP address that is basically my email address,
and my domain has SIP SRV records, there's a good chance
that I'm going to be found.

(Admittedly I'm less worried about the failure case because
2543 doesn't work in the reverse direction; therefore I feel
there are bigger problems.)

> - If a proxy inserts Record-Route header into a request
> without neither a Contact nor Record-Route header, then the
> Proxy MAY add a second Record-Route header to the end of the
> R-R list using the From URL address with the source address
> as an maddr parameter.
> 
> - If a proxy receives a response to a request in which it
> added a Record-Route header AND the response does not contain
> a COntact header AND no new headers have been added by other
> proxies (ie proxy is final Record-Route'd proxy), then the
> proxy MAY add another preceeding Record-Route header to the
> start of the response's R-R list using the request's
> request-URI with the request's forward address as an maddr
> parameter.

This is a funky algorithm, but I wouldn't recommend it as
default proxy behaviour.  Is this a case of intelligence at
the edges, simplicity in the core?  I feel that it is.
That said, I don't have much difficultly imagining some sort
of RFC2543 <-> RFC3000 [0] fix-up proxy that mediates
between older / newer implementations, and I would see this
algorithm being used there.  (It would also be possible for
it to perhaps enable RFC2543 UAs to be able to issue requests
in the reverse direction?  I'll have to think about this
some more.)

If no proxies Record-Route, and the called UA wishes to
re-INVITE, and it has no Contact, what does it do?  It uses
the From.  Thus appending the From seems to be consistent
behaviour to me (I imagine code would degenerate quite easily).

> This should cover the majority of RFC2543 scenarios without
> too much fuss for the proxy or UA - I think it is better than
> trying to embed using r-r parameters as this just gets messya nd
> brittle. As I said before, I think it is better that the
> proxy does this as it understand that it will use the added
> Record-Route. If the UA tries this, it has little chance of 
> success. A UA has never (if I remember correctly) added extra
> R-R headers if there is no Contact (and shouldn't matter even
> if it did).

Oh no, they shouldn't be Record-Route headers, just the normal
Route headers that a UA always builds in these scenarios.

Cheers,

 - Jo.

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 1 Dec 2000 19:16:28 -0800

> 
> > My point is the request-uri that the UAC sends, may quite likely be
> > different to the request-uri that the last record-route 
> proxy sees, eg
> >
> > UA sends with a request-uri of [email-masked]; a proxy changes this to
> > [email-masked]. The last proxy sees this URI not the 
> initial one.
> > Thus if the UAC adds it Request-URI to the last ROute entry 
> then its going
> > to really confuse things.
> 
> True.  However, I have great faith in optimistic routing.  How did
> the [email-masked] map to [email-masked] in the first place?
> Simple scenario: ua.com runs SRV, and angel had registered as being
> at plane6.hell.com.  Therefore, that Request-URI would still work.

Call forwarding, roaming, alias addresses (eg [email-masked] is
forwarded to actual employee SIP url), domain changing (eg
sip:[email-masked] to sip:[email-masked]); proxies mapping tel's to
ascii SIP URL's, ect etct etc.

> > That's worse than putting nothing - at least if the proxy 
> stores call
> route state then it can succeed - if the UA adds an
> > incorrect Route then the proxy has no choice but to blindly 
> follow the
> > (incorrect) Route header !!
> 
> The cases where I can see the proxy doing better than the UA is:
>  * There is some sort of temporal based routing
>  * The initial routing is obscure (i.e., not literally SRV based)
> But it is fair to say that the proxy will "win" in these cases.

See above.
 
> 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... (:&)

As I see it, adding the extra Record-ROute header in the no Contact case is
simply an easy way for the LAST proxy to store call state on how it will
forward a request to the UA (in the absence of the UA providing this info in
a Contact). [A lot simpler, in my mind, than trying to embed and retrieve
URL's and addresses in Record-Route URL parameters.]

Unrelated to the above, Jonathan, you had an opinion of whether it was a
MUST or MAY that 
- user name in Record-Route MUST/MAY be non-zero.
- Record-Route MUST/MAY be different in each direction (ie proxy MUST/MAY
locate and change R-R in response).

Are you still sticking to your guns on this or ambivalent. [invariantness
verse operational complexity] 

I originally liked the idea but I'm hard pushed to see that it really makes
things less brittle _in practice_ and so I am inclined to just leave it up
to the proxy.

Anyone have any other problems with what has been propsed (reposted below)?
Jo, if we want people to comment we should just propose actual bis text
changes - it worked last time. :)

Proposal:
-Record-Route headers must be SIP URL's. 
-The address in the SIP URL must be the UDP reachable address of the proxy
inserting the route.
-The username and any parameters added to the URL to the header are
implementation defined. 
-The Record-Route should use angle brackets. 
Ie, Record-Route: <xxxxx@proxyaddress:port;yyyyy=yyyyy>;zzzzz=zzzzz
where y are the implementation defined Record-Route URL parameters and zzzz
are the implementation defined Record-Route header parameters. xxxxx, yyyyy
& zzzzz may be empty (ie no restrictions)
-If multiple Record-Routes are added for the same request (ie, spiral
route), then each Record-Route added MUST be different so that they can be
distinguished.
-In the response to a Record-Route'd request, a proxy MAY change any
Record-Route header that the it originally generated. 
-A UAS must copy the Record-Route unchanged into the Route header; a UAC
must copy the Record-Route unchanged into the Route header, reversing the
order. A Route header is added if a Contact is added (as before). 
-If a proxy inserts the first Record-Route header into a request without a
Contact header, then the Proxy MAY add a second Record-Route header below
the normal R-R header which contains the From URL address with the source
address as an maddr parameter.
-If in a received final response which does not contain a Contact header, a
proxy finds that it has generated the first Record-Route header in the list,
then the proxy MAY add another Record-Route header to the top of the R-R
list which contains the original request's request-URI with the request's
forward address as an maddr parameter.

What about the 401 Unauthortized responses (and another one) where it can be
expected that another INVITE with the same Call-Id will be issued? The bis
recommends that they can also contain Record-Routes. Are we keeping this?
Should we make it more general (for the proxy) that any final response can
contain the Record-Route headers but UA's should only generate R-R's when
the stated property is met.

Robert.

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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 1 Dec 2000 19:50:49 -0800

> verse operational complexity] 
Perhaps you can think of it as a conditional invariant:

The request-uri always refers to the final destination unless the message
contains a Route header in which case the request-uri refers to the next
Record-Routed proxy.

Cheers,

Robert.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 3 Dec 2000 13:04:53 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, December 03, 2000 12:13 PM
> To: Jonathan Rosenberg
> Cc: 'Jo Hornsby'; Fairlie-Cuninghame, Robert; [email-masked]
> Subject: Re: [SIP] RECORD-ROUTE/ROUTE requirements
> 
> 
> Jonathan Rosenberg wrote:
> > 
> 
> > 1. the current bis mechanism of having the UA mangle the 
> record-route is
> > gone.
> 
> Are you talking about the UAS creating routes in the callee-to-caller
> direction or what other mangling?

The one about the UAS constructing the Route in the reverse direction
(callee to caller) based on combining the RR with the Contact/From.

> 
> > 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.
> 
> 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
> 

Nearly; these URLs probably don't meet the requirement of causing the
request to be routed to the server that inserted them, so an maddr would be
needed.

> Alice now sends subsequent requests as
> 
> Route: sip:bob@yahoo, sip:bob@acme, sip:[email-masked],
> sip:[email-masked]
> Contact: alice@from

Yes. 

> 
> 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

Nearly; it would also incldue the Contact from the request, so:

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

> 
> 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.)

If the proxy needs to have requests with different URIs in each direction,
then it would modify the URL in the RR in the response. If it doesn't do
that, then yes, it would need to rely on To/From to determine direction.
However, as long as the proxies aren't doing anything besides forwarding the
requests, the next Route header indicates where the request should go to, so
determining direction won't be needed.

> 
> 
> > 6. The RR inserted is largely at the discretion of the 
> proxy, subject to
> > (2).
> 
> Thus, the requirement for maddr insertion disappears, presumably.

IFF the request URI routes to that server specifically. The incoming request
URI in the original request probably does not have that property.

> 
> > 
> > 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.
> 
> 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.

Yes.

> 
> > 
> > Now, the issues of contention remain:
> > 
> > 1. should modification of the URL in the RR in the response 
> be MAY or SHOULD
> > or MUST
> 
> 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?

Yes. Performing this allows the URIs in each direction for subsequent
request to be different, and even be resolvable on their own to the
appropriate party.

-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: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Sun, 3 Dec 2000 19:31:01 -0800

Hi Jonathan,

I think we all appreciate how busy you (and Henning) are. We are all very
thankful that you are both so active on the list. 

> 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 would have thought that this is a good example FOR my suggestion. Only the
first and last proxy will have to remember how to route the call (by storing
state locally or adding an extra Record-Route). The two end proxies will be
unaffected by any of this bbehaviour 
- they will be the only proxy using the information they add, 
- they will only remember routing information if they discover they will
have not have route headers or Contacts later. 
- the extra Record-Route is taken directly from and to) the UA and _not_
interpolated end-to-end. Ie, the first proxy builds an extra Reocrd-Route
directly from the initial From+source address that it sees, the last proxy
would build a Record-Route from the forward request-URI+forward address that
it used.

In a security conscious environment, it is more likely that the something
funky might be done to the From or request-uri from end to end. My
suggestion does not make end-to-end assumptions but rather stores the
information as seen by the affected proxy.

As for not being able to route To/From URL's, I thought this was your
suggestion for global tel URL's, that is, place global tel URL's in the
domain namespace (since they are not really owned by anyone). Consider a
routing proxy that contains the tel url routing information and another SIP
gateway that just routes local numbers to the PSTN. So this could be the
Record-Routed INVITE sent to the gateway (after the proxy does it's
routing):

INVITE sip:[email-masked];user=phone SIP/2.0
To: 	[email-masked];user=phone
From: [email-masked];user=phone

Routing to the To/From URL's won't work in this case (as in many situations
I contend).

> 
> 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).
> 
Currently, I beleive we have only made the Contact mandatory in the INVITE
and OPTIONS 2xx response. In fact the Contact is disallowed in the
4xx,5xx,6xx response (except 485) [0], however I think it would be a good
idea to allow Record-Routes in any non-3xx final responses. Eg 401. So we've
got a couple of options: 

However, the UAS can't specify a 
- Record-Routes only allowed in 2xx responses and all Record-Routable
methods MUST include a Contact in the request, or 
- if a UAS copies the Record-Route into a non-3xx final response, then it
MUST also add a Contact. This really allows Contact in any final response.
All Record-Routable methods MUST include a Contact in the request, or
- Make it a MUST that the proxy is able to "remember" the routing action in
the absense of a Contact (either by storing state or adding an extra
Record-Route) so that any proxy can always handle a Record-Route without a
Contact. 
- something else.

By the way, the bis suggests that 484 Address Incomplete responses may use
Record-Route. This doesn't make sense to me as there is no way that the UAC
can convey the new request-URI to the UAS. Am I missing something?

Regards,

Robert.

[0] Section 6.14 [Contact] disagrees with Table 5. 6.14 says that Contact
may carry error-informations. I believe this is now in Error-Info and should
be removed from 6.14 - the Contact is already very overloaded.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 4 Dec 2000 00:18:04 -0800

> 
> I just can't follow what you are saying.
> 
> My point is simple. You are making assumptions about the meaning of a
> missing Contact. I gave an example where the Contact was 
> missing for a good
> reason. Insertion of it by another proxy may confuse the 
> proxy that gets a
> record-route back in a response that does not have the form 
> it expected
> (i.e., extra entry corresponding to the inserted Contact).

Hi Jonathan,

Ok firstly, I am not advocating a proxy inserts a Contact. I agree this is a
bad idea - that is not my suggestion. I was merely suggesting a method
whereby the proxy can stateless remember where to send a request when there
is no COntact when the proxy is the first or last proxy. 

If the proxy doesn't remember the state information:
Then Contact field MUST always be present when Record-Route is used or you
must be able to route to the To and From. I don't understand your position:
on one hand it seems you are saying the Contact is mandatory and on the
other hand you are saying you should be able to work without a Contact. 

So should a call succeed if the UA doesn't add a Contact or if a proxy
strips it? Under what conditions? This assumes that the From URL (reverse
direction) and To URL (forward direction) are directly routable ? I can live
with the former assumption (From); the latter in my mind is unacceptable[To
is routable by last proxy without causing loops]. I believe there may be
advantages to allowing the forward direction to work without a Contact in
the final response (see below). 

Options for storing the required information (statelessly):
- Embed request-uri and source addresses to Record-Route. 
- Edge proxies add extra Record-Route with forwarding information (as
previously suggested - no r-uri quoting needed).

Ok, you don't like the latter suggestion so how about the former? To get
around the complexity of quoting the r-uri, the proxy could code the r-uri
to base64 as was suggested by Henning. Actually I think I like that idea
better than my original R-R adding suggestion. 

> I don't see how your point addresses what I was saying.
> 
> My point was that this whole discussion is likely moot, since it is my
> suspicion that Contact is inserted by most UAs already.

My point is: 
Should Record-Routing be allowed for non-2xx response? (yes, I believe)
However, Contacts are not allowed for 4xx,5xx,6xx responses so what are we
going to do ? Simply mandating Contact's on error responses adds
requirements to how the UA forms the Contact (to statelessly reproduce
request-URI) and/or how a UA correlates failed requests with successful
requests. Not a good idea in my mind.

Why not three kill birds with one stone and make the Record-Route work
flawlessly if the _response_ doesn't have a Contact and "best-effort" if the
request doesn't have a Contact. 

So my suggestion is now:
-If a proxy receives a response AND the first Record-Route header was
generated by the proxy AND the reponse does not contain a Contact, then the
proxy MUST be able to reproduce the forward routing action for subsequent
forward requests. Eg, by either embedding information into the Record-Route
URL or storing the information locally. [Base-64 encoding of r-uri
recommended in R-R URL.]
-If a proxy recieves a request without any Route headers AND the request is
known to be a previously Record-Routed call-leg request travelling in the
_reverse_ direction, then the proxy SHOULD forward the request to the From
URL (unless more detailed information is known).
-If a proxy embeds forwarding information into a Record-Route URL (eg, due
to the absence of a Contact in the response) then the MUST the proxy must be
able to determine the direction of a received call-leg request from the
Record-Route URL (so requests aren't forwarded in the wrong direction).

[Proxy can simply & statelessly achieve this by always embedding directional
and request-uri information in the Record-Route header of requests (response
can then be left untouched).]

As you say, the point becomes moot if you decide that Contacts are 100%
mandatory in all final responses but I think that deserves some thought
first. 

Robert.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Dec 2000 13:11:44 -0500

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Monday, December 04, 2000 3:18 AM
> To: 'Jonathan Rosenberg'; 'Jo Hornsby'; [email-masked]
> Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements
> 
> 
> > 

My apologies for a confused response. I wrote this when I was way too tired.
The To/From have nothing to do with it, and we do need to worry about the
case of UAs that don't insert Contact. Lets start again.

OK, so here's what happens when A calls B and neither inserts a Contact. 

On a re-INVITE from A to B, the request ultimately arrives at the proxy
right before B. Now, since the request has no Route header at all, the proxy
doesn't know the difference between this and a regular initial INVITE. So,
it does the normal thing. It looks at the request URI, and uses that to
determine where to forward the address. Now, if the request URI had the
property that it is translated to the same next hop server (the UAS, in this
case), as the initial INVITE, things work fine. The same is true in the case
of a re-INVITE from B to A; if the request URI there causes a translation to
A, things work fine.

Now, if record-routing had the property that I have been advocating all
along in this thread (the URI inserted into the request maps to caller, and
the URI placed into the response maps to the called party), we wouldn't need
to worry about special case handling of the missing contact scenario. But,
if you insist on Record-routing with things like sip:myproxy.com, then you
are going to NEED to do something weird, like inserting extra record-routes
or contacts or something like that, for this all to work with UAs that don't
insert Contacts. Otherwise, the proxy gets a request with request URI of
sip:proxy.com, and then what?

So, proxy implementors have a choice when record-routing. Use the approach I
have been advocating, which is not so hard and works universally, and is
also the most robust, or, insert weirdo things into the RR in the request,
change nothing in a response, and then implement special case handling for
the cases where the UAS and/or UAC don't support Contact.

So, as you say, I'd rather kill many birds with one stone, and have a single
mechanism that handles all the cases we need to worry about.

-Jonathan R.

---

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 5 Dec 2000 17:35:39 -0800

> mechanism that handles all the cases we need to worry about.

Ok great we agree.

So the requirement on the funcionality is that: a proxy MUST be able to
reproduce the forward direction routing action (ie forward request-uri and
transport details) in the absence of Route headers on subsequent callleg
requests. This may be accomplished using either stored local callleg state
or information embedded into the Record-Route URL (and retrieved in the
Request-URI). For requests in the reverse direction, Route-less requests may
be forwarded to the From URL at the original source address (if this is
known). 

Request-URI information embedded into the Record-Route URL SHOULD NOT be
inserted without first encoding teh URL into base64 format or someother
encoding scheme. Straight quoting of a Request-URI does not allow unambigous
reconstruction. A proxy SHOULD also be able to determine the direction of a
received request from the Record-Route (when received as Request-URI). 

The suggested method for achieving this behaviour statelessly is for the
proxy to insert a Record-Route header in the request which indicates the
reverse direction, eg

Record-Route: <sip:[email-masked];rr-addr=100.56.34.21>

and when the response is received, the proxy changes its Record-Route header
to the forward direction and adds forwarding information, eg

Record-Route:
<sip:[email-masked];rr-uri=78786AB88CedjjH7656ehkkiKJDS;rr-addr=56.45.2
3.12>

For robustness, this SHOULD be done even if there are preceeding
Record-Route headers in the header list (other proxies may remove themselves
from the Route lists at a later time).

If multiple Record-Route headers are added to a single call-leg request (eg
spiral routes) then they MUST be distinguishable, eg

Record-Route: <sip:[email-masked];rr-addr=100.56.34.21>

What do people think? It's readable, fairly simple and robust. Just placing
encoded data in the user part isn't very readable. eg
sip:[email-masked] does tell you anything about
what the porxy is trying to do (eg, direction).

Robert.

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 5 Dec 2000 20:39:36 -0800

> be forwarded to the From URL at the original source address 
 
Or alternatively (for the lazy stateless record-routing proxy), you could
simply include the From URL and the request forwarding information in the
request's Record-Route header.

Record-Route: <[email-masked];
		rr-from=43237du8d8d8Eud63f8Fd63;rr-faddr=123.43.78.122;
		rr-uri=784ff76v8f8f83dfgFd2sDfd799;rr-raddr=54.23.1.42>

This means the proxy can always determine the direction (from matching the
From) and how to forward a call leg request AND it doesn't require the proxy
to examine or mess with the Record-Route headers in the response (at the
cost of a lot of bandwidth).

[Of course this is all up to the proxy how to achieve the required behaviour
..... but just to prove its possible to statelessly not mess with the
response.]

Robert.