[Sip] Vocabulary and problem statement for Request-URI, retargeting, and SIP routing (long, but read it!)

The ongoing discussion around parameter passing mechanisms is getting  
wrapped up in some concepts that we really haven't yet described well  
enough to be communicating clearly. This message is an attempt to  
develop a better understanding of the basic problem.

Even given something as simple as a "SIP proxy", we have three  
fundamentally different modes of operation, and one of those modes  
has two sub-cases that require different thinking.

In the first fundamental mode, the destination of the request is not  
changed by the proxy. The proxy gets the request, looks at it, and  
makes a best guess as to where the request should be sent so as to  
get the request closer to the destination encoded in that request.  
This is roughly analogous to IP routing, where the router does not  
change any of the addresses encoded in the packet. I call this  
fundamental mode "request routing".

In the second fundamental mode, the proxy alters the target of the  
request. Under RFC 3261 as-is, this means that the request-URI is  
changed by the action of the proxy. In general, I call this  
fundamental mode "request retargeting", except that our vocabulary  
isn't completely consistent here. Incidentally, while the first  
fundamental mode is roughly analogous to IP level routing, this  
second fundamental mode is more similar to IP-level network address  
translation. Yes, we've re-invented NAT. For the purpose of future  
clarity, I propose we start calling this fundamental mode "request  
translation".

There are two sub-cases of the second fundamental mode -- that is,  
two kinds of request translation.

In the first sub-case, the proxy transforms the request-URI in a way  
that preserves the identity of the target. That is, the request is  
still going to the same distinct entity, it's just using a different  
request URI to get there. This is what happens when a "home proxy"  
does what I have in the past called "contact routing" and the  
original request URI is transformed from an AOR into a contact URI  
registered against that AOR. The important thing here is that it is  
reasonable for the message sender to expect the message recipient to  
be able to authenticate using the identities expressed in the To:  
header field, which is in general the same as the identity expressed  
in the original Request URI -- that is, as the AOR. So for example:  
sip:Bob@example.com registers from sip:Bob@192.168.1.1. Alice calls  
sip:Bob@example.com. Bob's proxy transforms this to  
sip:Bob@192.168.1.1. Bob gets the request, extracts the To" header  
field, and could reasonably insert an Identity header into the  
response claiming to be "sip:Bob@example.com".

As I said, I've previously called this first sub-case "contact  
routing". We probably shouldn't, since properly it is a translation  
(the request URI changes), not routing. I suggest that we call this  
"translation with preservation of target identity" until somebody  
comes up with a catchier name. The most common example of translation  
with preservation of identity is probably the "home proxy" applying a  
Contact:, which we might call "contact translation". Perhaps we could  
use "rerouting" as a short name, and use "contact rerouting" for the  
thing that a home proxy does.

In the second sub-case of the second fundamental mode, the proxy  
transforms the request URI in a way that does NOT preserve the  
identity of the target. That is, the request is going to a distinctly  
different entity from that indicated by the original request URI and  
the To: header field. Such a case arises if Bob forwards his calls to  
Charlie. Alice sends a request to "sip:Bob@example.com" and gets back  
a response can only be authenticated as being from  
"sip:Charlie@example.com". It is this second case that gives rise to  
the unanticipated response problem and has lead people to propose  
that all retargeting be replaced with redirection. We might call this  
sub-case "translation without preservation of target identity". We've  
often called this sub-case "retargeting" in the past.

We also have a third fundamental mode, "redirection". In this mode,  
the proxy sends a response that encodes a new target for subsequent  
requests. The identity of this new target is independent from the  
identity of the original target -- it may or may not be the same, and  
the act of redirection says nothing about this relationship. As an  
example, Alice calls sip:Bob@example.com. The proxy at example.com  
sends Alice a response redirecting her to "sip:carol@example.com".  
Alice then calls "sip:carol@example.com".

So to recap, we have three basic proxy operations in RFC 3261:

1) Request routing, which preserves the request URI.

2) Request rerouting, which changes the request URI but preserves the  
identity of the request's target.

3) Request retargeting, which changes the request URI and changes the  
identity of the request's target.

We also have a related operation:

4) Request redirection, which informs an upstream node about a new  
identity to target instead of the original.

As a further layer of complexity. note that these proxy operations  
can be stacked. That is, we might, in the process of dealing with one  
request, see multiple applications of the first three, followed by an  
application of the fourth.

Leaving the unanticipated response problem aside, we have two  
fundamental problems with both rerouting and retargeting. The various  
Called-Party-ID, Target, UA-Loose-Route,and other such mechanisms are  
attempting to solve these problems. History-Info provides a related  
set of solution that also encompasses request redirection.

Problem 1: Expressing the identity that was originally the target of  
the request.

Problem 2: Delivering any end-to-end parameters that might have been  
encoded in the original request URI. Note that this is complicated by  
the possibility of end-to-middle parameters that need to be stripped  
by a mid-path node.

We also have a related problem that, AFAIK, neither CPID, nor Target  
nor UA-Loose-Route attempt to solve, but that History-Info does  
attempt, which is:

Problem 3: Expressing what operations have occurred, and WHY they  
have occurred, in such a way that the target, mid-path boxes, and/or  
the requester can do something useful with this knowledge.

I've always held that this last problem is infinitely complex and  
that we should not try to solve it in the general case, which  
explains my reluctance to attack the History-Info problem (or indeed  
the old Diversion header, which also tickled part of this problem  
space). Building applications that require Ultimate Understanding  
seems to me to be a Bad Idea. Much as the invention of time travel  
will have made the concept of future-perfect tense untenable (the  
future will have been found not to have been perfect after all), so  
too is the concept of Ultimate Understanding untenable -- if you know  
everything, you can't possibly understand it since understanding  
requires knowledge outside the subject being considered, and if you  
understand everything you know, you'll understand you don't know  
everything. And that sums up the way I currently feel about the whole  
US-Loose-Route/CPID/Target discussion.

Conclusion:

New proposed vocabulary for proxy operations: request routing,  
rerouting, retargeting, and redirection.

Call for clarity on exactly which problems we're solving with UA- 
Loose-Routing, target, CPID, etc. Proposed: target identity, end-to- 
end parameters.

--
Dean Willis

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip