Subject: RE: [SIP] Pre-loaded Route headers

From: "Shantala Manchenahally" <[email-masked]>
Date: Fri, 3 Nov 2000 13:42:18 -0600

Hi,

Just a few thoughts on the matter..

I agree that a Record is stripped before it gets to the Proxy. However if a
proxy see's a Route Header (specifying the next hop)in the initial request,
it can decide to add itself to the Record-Route. If every Proxy along the
path
obeys this rule then the pre-loaded route will be preserved for all
subsequent transactions. 

This wouldn't work for the cases where the pre-loaded Route doesn't specify
all the hops
between the UAC and the UAS. So a Proxy may not see a Route header at all,
even though the initial message did contain a Route header.

So I would think that a pre-loaded Route can effectively be applied for that
transaction alone.

Shantala.

-----Original Message-----
From: Jonathan Lennox [mailto:[email-masked]]
Sent: Friday, November 03, 2000 12:47 PM
To: [email-masked]
Subject: [SIP] Pre-loaded Route headers

I've been pondering details of the concept of "pre-loaded" Route headers --
Route headers that go in the initial transaction of a call, used to direct a
call to go through an outbound proxy server.

My question is, if you pre-load a Route header into an initial INVITE, do
those Route headers have to persist for the rest of the call?  Or do
subsequent transactions just build their Route headers based on the
Record-Routes that were inserted in that first transaction?

I think it would have to be the latter, since the destination UAS doesn't
see any of the pre-loaded Route headers.  The UAS is going to all its
routing based on those initial Record-Routes -- all the pre-loaded Routes
are stripped by the time the request gets to the UAS.

I was going to suggest that if you get a request with your own Route header
in it you be required to insert yourself as a Record-Route -- until I
remembered that you don't see Route headers for yourself.  (This causes a
lot of headaches, it seems.)

The problem is that this seems to be asymmetric with how Route headers
persist *after* the first transaction -- 2543bis says they remain even if
subsequent transactions don't put Record-Routes in for them.  This may be
the correct behavior, but it should probably be called out explicitly.

Thoughts?

-- 
Jonathan Lennox
[email-masked]

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

---

From: William Marshall <[email-masked]>
Date: Fri, 3 Nov 2000 16:01:41 -0500 (EST)

I believe there may be a problem with Pre-loaded Route headers and
stateless proxies, but it not a difficult one to solve.  But there
are side-affects that are not nice.

An initial INVITE is normally the one that accumulates the Record-Route
values; then they are stored at the UAS and converted into a Route header
for UAS->UAC transactions, and echoed back to the UAC in the 200-OK so
the UAC converts them into a Route header for UAC->UAS transactions.
A mid-call INVITE (or any other message) contains the Route header
value, but doesn't need to accumulate Record-Routes again.

But a stateless proxy can't really tell the difference between an
initial INVITE for a new session (one in which it should add itself
to the Record-Route) and a mid-call INVITE for an existing session (in
which it doesn't need to add itself).  So it has two choices: 1) always
add itself to a Record-Route, or 2) note there is a Route header and
assume therefore it is a mid-call message and do nothing.

Keying on the existence of a Route header to indicate a mid-call
message isn't explicitely disallowed by the spec (unless I missed
it somewhere), but it would work just fine - until a UAC tried to
use a pre-loaded Route header.  Then the proxy wouldn't get itself
into the Record-Route when it should.

So the solution is to have the proxy insert itself into the
Record-Route header *independent of whether it is an initial INVITE
or a mid-call INVITE*.  

Unfortunately there is a backward compatibility problem here - a proxy
that doesn't know to do this for a mid-call message will be dropped
from future messages.  If even one proxy along the path inserts a
Record-Route header on the mid-call message, the UAS and UAC will
trigger their Route re-calculation.  (Presumably if none of the proxies
did the Record-Route for a mid-call message, the UAC and UAS would
act like currently, and keep the Route from the initial INVITE).

Is this just a theoretical problem, or does it break real proxy
implementations?

Bill Marshall
[email-masked]

---

From: "Singh, Manish" <[email-masked]>
Date: Fri, 3 Nov 2000 17:26:28 -0800

Hi :

If any proxy inserts a Record-Route header in mid-call
message, how will UAS and UAC re-calculate the Route
header?

A -INV-> P1 -INV(RR:P1)-> P2 -INV(RR:P1)-> B

In this case P1 decides to add Record-Route header
in the intial Invite, however P2 doesn't.

Now, if 'A' sends a re-Invite, the Route header mandates
only P1 to be in the path. However, if P1 proxies 
this re-Invite to another proxy P2' this time (depending
on SRV records), and P2' policy is to add Record-Route
in the mid-call message, when the re-Invite reaches
'B', how will it re-construct the correct Route header.

To examplify, pls consider these secnarios -

1. It is possible, that after P2, there is another
proxy P3, and P3 in the initial Invite had also 
added Record-Route, so the Route at 'B' was P3, P1.
With P2', in the Re-Invite case, it should then be 
P3, P2', P1.

A -> P1 -> P2 -> P3 -> B (Original Invite Path)

A -> P1 -> P2'-> P3 -> B (Re-Invite Path)

2. If P3 in the initial Invite was prior to P2, then
the initial Route at 'B' was still P3, P1. However,
after re-Invite it should be P2', P3, P1.

A -> P1 -> P3 -> P2 -> B (Original Invite Path)

A -> P1 -> P3 -> P2'-> B (Re-Invite Path)

So, how will UAS re-calculate the Route header?

Is there something I am missing?

Comments?

Thanks,
Manish Singh

-----Original Message-----
From: William Marshall [mailto:[email-masked]]
Sent: Friday, November 03, 2000 1:02 PM
To: [email-masked]
Subject: [SIP] Re: Pre-loaded Route headers

Bill Marshall
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2000 02:56:34 -0500

Comments below.

> Sent: Friday, November 03, 2000 4:02 PM

We had an extensive discussion on the list on just this topic. The result of
that discussion is already in the bis draft:

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

So, what this is saying is that a proxy should always insert the
record-route, but a UA doesn't reload the record-routes if it has a set
already. This avoids the backwards compatibility issue. But, you ask, what
is the point of re-inserting them? THe answer is twofold. First, the
original idea is recovery from crash and restarts. The restarted UA wouldn't
have a record of the Record-Routes, and so when it gets a re-INVITE (via
session timer, perhaps), it will re-establish the route based on the
record-routes in the INVITE. Secondly, we have our recent discussion of
sending invites with loaded routes. If proxies follow the above
recommendation, they will always record-route, and the result is that the
initial forced route will actually get persisted, since the UAS has no
memory of a route when the initial request arrives.

So, what we need here is a little motivational text so people notice this
subtelty and implement it correctly, along with a reccomendation that
proxies SHOULD NOT consider a request with a Route header as indicative of a
mid-call or mid-session message.

-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: William Marshall <[email-masked]>
Date: Tue, 7 Nov 2000 09:59:05 -0500 (EST)

There is informative text at the beginning of 6.34.1, and
also informative text in 6.34.2.  However, they contradict
each other.  There is no normative text for this situation
at all.

See, for example, lines 3-4 of 6.34.2:
  A UA builds the Route header field for subsequent requests
from the Record-Route header fields received in either a
response or a request.

I would take this to explicitely allow a mid-call change
of Record-Route/Route values.

What is needed is some normative text about the handling
of Record-Route in UAC/UAS/Proxies.  I believe the workable
combination is:

UAC:	MUST convert the Record-Route to a Route
	on the final response to the first request
	of a call leg, and use it for all future requests
	with the same call-leg identification.

	MUST convert the Record-Route from a provisional
	response into a Route for use solely in a
	PRACK and COMET.  
(This requirement is from 100rel, and was copied into manyfolks, but I 
don't understand how it might be different than first case above - unless 
it intends to allow mid-call requests with provisional responses to take 
a different route.)

	MUST NOT update Route value based on any Record-Route
	received in a subsequent request/response with the
	same call-leg identification.

UAS:	MUST convert the Record-Route to a Route on the
	first request with a new call-leg identification.

	Within a single transaction, MUST include the value of
	Record-Route received in the request in every
	response that requests a PRACK.
(Should this instead be to include the value of Record-Route received
in the first request with the same call-leg identification, to remove
the dependance on proxies doing the right thing?)

	MUST NOT update Route value based on any Record-Route
	received in a subsequent request/response with the
	same call-leg identification.

Proxy:	Either (1) MUST insert itself into the Record-Route
	header in every request for a particular call-leg
	identification, or (2) MUST NOT insert itself into
	any Record-Route header for a particular call-leg
	identification.
(Note this is a SHOULD in case #1 in 2543bis)

The proxy behavior is difficult for a stateless proxy, unless it makes the 
decision (to be in the Record-Route or not) independent of call-leg 
identification.

I believe the above requirements have the property that, if the proxies
do the right handling, the UAC/UAS can botch the handling and still be OK.
Further, if the UAC/UAS do the right handling, the proxies can be wrong
and everything will still work OK.

Bill Marshall
[email-masked]

-----original message-----
From: Jonathan Rosenberg <[email-masked]>
To: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [SIP] Re: Pre-loaded Route headers
Date: Tue, 7 Nov 2000 02:56:34 -0500

Comments below.

-Jonathan R.
---