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:[EMAIL PROTECTED] registers from sip:[EMAIL PROTECTED] Alice calls
sip:[EMAIL PROTECTED] Bob's proxy transforms this to
sip:[EMAIL PROTECTED] Bob gets the request, extracts the To" header
field, and could reasonably insert an Identity header into the
response claiming to be "sip:[EMAIL PROTECTED]".
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:[EMAIL PROTECTED]" and gets back
a response can only be authenticated as being from
"sip:[EMAIL PROTECTED]". 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:[EMAIL PROTECTED] The proxy at example.com
sends Alice a response redirecting her to "sip:[EMAIL PROTECTED]".
Alice then calls "sip:[EMAIL PROTECTED]".
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
