There seems to be a misunderstanding here, there is no intention for stacking Target headers at all. There will always have to be zero or one target header field with one clear meaning: "current target".
As soon as a retarget (using the definition from UALR draft) occurs an existing target header will have to be removed, as it no longer represents the current target. Params only seems to tackle the parameter loss issue, and it seems further to solve a different problem alltogether i.e. how to get parameters from the caller to the callee. There is a risk that parameters that where only intended to be received by user B end up at user C. /Hans Erik -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Willis Sent: Friday, April 04, 2008 9:07 AM To: sip@ietf.org List Subject: [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:[EMAIL PROTECTED] SIP/2.0 From: sips:[EMAIL PROTECTED] To: sips:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] Via: SIP/2.0/TLS alice.example.com:5061;branch=z9hG4bKnashds7 Params: role=ua,src=sips:[EMAIL PROTECTED],MyAppID=23 Message 2: (note no new Params) INVITE sips:[EMAIL PROTECTED] SIP/2.0 From: sips:[EMAIL PROTECTED] To: sips:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] 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:[EMAIL PROTECTED],MyAppID=23 Message 3: (retargeting occurs) INVITE sips:[EMAIL PROTECTED] SIP/2.0 From: sips:[EMAIL PROTECTED] To: sips:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] 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:[EMAIL PROTECTED],MyAppID=23 Params: role=proxy,src=bproxy.example.com,target=<sips:[EMAIL PROTECTED]> Message 4: (note no new Params) INVITE sips:[EMAIL PROTECTED] SIP/2.0 From: sips:[EMAIL PROTECTED] To: sips:[EMAIL PROTECTED] Call-ID: [EMAIL PROTECTED] 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:[EMAIL PROTECTED],MyAppID=23 Params: role=proxy,src=bproxy.example.com,target=<sips:[EMAIL PROTECTED]> So with this request, Bob's UA can look at it and say "Ok, this requested is targeted to sips:[EMAIL PROTECTED], 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 [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.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
