[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Long: Thoughts on "retargeting proposals"
Sorry about the HTML formating. I'm too lazy to wrap my lines. And
yes, this should probably be in an ID, but I'm too lazy for that too.
Here's why the answers seem to be confusing -- the question is
confused. I'd like to try and rein it in a bit, and make a proposal.
We have a couple of things we want:
1) Delivery of application-specific info (aka "parameters") from the
originating UA to the terminating UA
2) Delivery of parameters from proxies to the terminating UA
3) Information to allow the terminating UA to know which application,
function, or identity (or something else) at that UA is being targeted
by the request, over and above the mundane aspects of the request such
as ordinary headers and bodies. Presumably this information is
inserted somehow along the way, either at the source UA or some
intermediate (proxy or the like) node. This information may, or may
not, be the same as #1 and #2 above.
4) We think we have a need for the terminating UA to figure out who
inserted each bit of information. I find this compelling.
5) We think we have a need for the terminating UA to understand the
entire decision tree that resulted in the call arriving at it. I don't
find this compelling at all (which is why I opposed Diversion and
History-Info), as I think that every application people THINK they
need this for is more readily addressed by 1-3.
These "needs" have been getting tangled up in the most perniciously
confusing sorts of ways I can imagine. We have History-Info,
Diversion, P-This-That-And-the-Other-Thing, and probably a couple of
dozen other hackneyed ways to work around this problem. Quite
probably a large number of the SIP extension headers we've documented
have been narrow application-specific functions that really didn't
need an RFC, but since an RFC is required to get a header, we've had
to do a lot of work.
Why don't we have an easy answer?
The problem starts with SIP's take-off from HTTP. If we were using
HTTP, we could use request-URI parameters to talk to the application.
This works very well in HTTP land, since outside of very specialized
cases, HTTP proxies don't change the request URI, and when they do
it's an additive thing ; they add parameters as needed. Note that
neither IETF nor W3C has found it needful to standardize HTTP request
parameters. Any fool can code up a CGI script that uses new ones, and
the neat thing is, they're always scoped to the application in use.
Let's look at the request for my Google home page:
http://www.google.com/ig?hl=en&source=iglk
This conveys the location of the target node, an application
identifier, and two parameters delivered to that application. The
target node is www.google.com, the application is "ig", and the
parameters are "hl", which has a value of "en", and "source", which
has a value of "iglk".
RFC 2543 just didn't work this way. Every proxy mangled the request
URI to the best of its ability, such that there was absolutely no way
to use the request URI to pass any useful information between UAs. I'm
not sure why we went down this path. I argued against it at the time,
but obviously I lost that argument. We partially fixed this with loose
routing in RFC 3261, but we didn't fix it well enough, and we still
have the problem. Jonathan's UA Loose Routing draft has tried to get
us closer to the HTTP model (but do so with full backward
compatibility), and lots of people have complained about the apparent
resulting complexity. It shouldn't be complex -- it's so easy with
HTTP, but SIP just isn't HTTP anymore.
We've tried putting stuff into body parts, and the ongoing war over
proxy manipulation of body parts and requirements for multi-part MIME
has been running for years now. Besides, we don't really have a way of
indicating which body part does what, as the MIME syntax just doesn't
give us a handle on it.
We have P-Called-Party-ID, which satisfies a subset of problem #3 by
letting the terminating UA know which identity at that UA the request
is targeting (and this COULD be used to indicate an application as
opposed to a user, I suppose).
We also have Target, a header that as proposed provides a sort of
partial combination of 3, 4, and 5 by basically stacking up another
header instance every time a proxy changes the request URI. As I
understand the author's intentions (which is not what I get from the
draft), the idea is that every URI seen on the path from UAC to UAS is
recorded in an instance of the Target header, One can then read the
list backwards, and sort of guess which one was inserted by various
proxies and maybe figure out which one was inserted by the originating
UA. I mostly like what I think I understand of the author's
intentions, but it's not QUITE what I want.
And I have a head ache from trying to sort this stuff out.
So here's a suggestion for a Radically Different Approach.
Let's define a new SIP extension header field. I call it "Params" for
now.
Eachs Params header field contains one or more parameter=value pairs.
The only mandatory of these pairs encodes the role (UA, proxy) and
identity of the node inserting the Params field. Another pair might
encode the URI targeted by the request as it leaves that node (which
is probably only useful for debugging). Another pair might encode the
identity targeted by the request, which as we know is not the same as
the URI of the request. Still more pairs would encode any parameters
being delivered to the UAS terminating the request. We also need a
rule: only insert a Params if you expect it to be useful to the
terminating UAS. If you aren't changing something , DON'T PUT ONE IN!
So, here's an example (with many fields left out)
Alice-1-->AliceOutboundProxy--2-->BobHomeProxy--3--
>BobOutboundProxy--4-->Bob
Message 1: (note that the param MyAppID=23 is encoded by Alice)
INVITE sisp:bob at example.com SIP/2.0
From: sips:alice at 192.168.2.1
To: sips:bob at example.com
Call-ID: 1j9FpLxk3uxtm8tn at 192.168.2.1
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:alice at 192.168.2.1,MyAppID=23
Message 2: (note no new Params)
INVITE sips:bob at example.com SIP/2.0
From: sips:alice at 192.168.2.1
To: sips:bob at example.com
Call-ID: 1j9FpLxk3uxtm8tn at 192.168.2.1
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:alice at 192.168.2.1,MyAppID=23
Message 3: (retargeting occurs)
INVITE sips:bob at 192.16.2.2 SIP/2.0
From: sips:alice at 192.168.2.1
To: sips:bob at example.com
Call-ID: 1j9FpLxk3uxtm8tn at 192.168.2.1
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:alice at 192.168.2.1,MyAppID=23
Params: role=proxy,src=bproxy.example.com,target=<sips:bob at example.com>
Message 4: (note no new Params)
INVITE sips:bob at 192.16.2.2 SIP/2.0
From: sips:alice at 192.168.2.1
To: sips:bob at example.com
Call-ID: 1j9FpLxk3uxtm8tn at 192.168.2.1
Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS aoproxy.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS bproxy.example.com:5061;branch=z9hG4bKnashds7
Via: SIP/2.0/TLS boproxy.example.com:5061;branch=z9hG4bKnashds7
Params: role=ua,src=sips:alice at 192.168.2.1,MyAppID=23
Params: role=proxy,src=bproxy.example.com,target=<sips:bob at example.com>
So with this request, Bob's UA can look at it and say "Ok, this
requested is targeted to sips:bob at example.com, so I'd best respond
appropriately. And oh look, the originating UA wants me to know that
MyAppID=23." Diagnostically, we can also look at it and see that there
was a retargeting at the proxy bproxy.example.com, since said proxy
was kind enough to insert the Params telling us so.
Ok, now I can hear people screaming "But this is what History-Info
does!"
That might be. I'm not sure I actually understood History-Info. But
this seems a bunch simpler, AND it allows for inclusion of "forward
knowledge" (i.e., parameters inserted under application control)
rather than only "backward knowledge" (a record of the decisions that
got us here). Hence RFC 3087 / RFC 4458 type control mechanisms can be
used effectively. Hint: If you have a voice mail application that is
dependent on knowing that a retargeting decision resulted from a busy
condition, it's easy to put a "cause=busy" into the relevant Params.
Note also that this doesn't seem to capture the full range of History-
Info cases. I think it is a simpler replacement that gives the
required functionality. And since it's just new extension header
fields, it is 100% backwards compatible.
There are also some interesting anonymization interactions. For
example, if you don't want to reveal a source, use anonymous or a temp-
gruu in the "src=" Params. Or better yet, don't insert a Params at
all! They're optional except when rerouting or retargeting.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip