Dale, There is a new version of the draft. http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt This has only 3 requirements :) . Not sure your intention is to comment on the old one or you didn't notice the new one. Some of the comments you mentioned are not applicable in 01 version. Some folks in this mailing list mentioned about 3pcc to achieve the behavior. As you mentioned in your first Para probably it works only if the sip body is SDP. In this case actually SIP is not providing the mechanism. Its the SDP which is providing the mechanism. The problem statement in this draft needs to be stated as a SIP mechanism to correlate the dialogs as apposed to other mechanisms like SDP. Regards Krishna ________________________________ Från: sipping-bounces@xxxxxxxx genom Dale.Worley@xxxxxxxxxxx Skickat: må 2008-12-08 17:35 Till: sipping@xxxxxxxx Ämne: Re: Comments ondraft-loreto-sipping-context-id-requirements-00 People have been discussing alternatives to the concept of correlating separate dialogs in order to present them as parts of one (user-centered) communication session. The ideal solution seems to be to use one dialog containing SDP that describes all the associated media streams. SDP allows this, as each stream can have a separate c= line. But in some cases, this won't work. E.g., if an IM conversation has been progressing using MESSAGE requests. (And MESSAGE seems to be how SIP-enabled IM clients send IM.) In that case, there's no SDP to be revised to include an audio or video session. In regard to correlating simultaneous dialogs, there are complexities that I don't think we've thought through. E.g., the draft proposes that one UA decides to initiate a video stream, but must activate a separate UA to start the stream. But what happens if there is an incoming request to initiate a video stream? How is that routed to the separate video UA, with proper correlation with the existing audio UA? (And there are two flavors of this: (1) the request is a separate-but-correlated INVITE, and (2) the request is part of the SDP in a re-INVITE of the original dialog) I'd feel much more comfortable knowing that the full consultative-transfer sequence had been worked through, with various combinations of (1) integrated UAs that can handle all the media at one time with (2) UA clusters that use the correlation mechanism. In regard to Reqs. 1 and 2: The talk of "applications" seems to be incorrect here. A better phrasing of Req. 1 would be "It MUST be possible to correlate a SIP Request (e.g. MESSAGE) sent out outside of a dialog with a specific other dialog." The SIP standard does not speak of applications, and there is no necessary correlation between applications and dialogs. If the correlated-to dialog may already have been terminated, this needs to be noted explicitly, since most SIP correlation mechanisms fail if the referred-to dialog no longer exists. Similarly, we need to ask what happens if the correlated-to dialog does not yet exist (as may happen in race conditions). In regard to Req 4: "The Context ID shall be an End to End value." First, this assumes that the correlation mechanism will be a Context ID value, which is not stated explicitly as an assumption. Second, this is not so much a constraint on the solution, as a relaxation of requirements, because the real meaning is "We do not require the mechanism work with dialogs that pass through B2BUAs unless the B2BUA passes the Context ID without change." But as Hadriel's draft shows, there are perceived security/privacy questions regarding such values, and we can assume as a default that B2BUAs *will* delete such values. This makes an explicit Context ID mechanism less likely to work in initial uses. There is also the question of whether we can create the initial dialog without knowing in advance whether another dialog will want to correlate with it. In the call-completion work, we took as an assumption that call originators would not be willing to tag each call with a special value just so that a small minority of calls could later have call-completion applied to them. In regard to Reqs. 5 and 7, a better phrasing is "The correlation mechanism shall not be required to operate between dialogs that are separated by more than a certain Time To Live, which shall be controllable by the UAs." But it's not clear why a TTL is needed. Of course, context IDs that are old enough will probably be unusable due to application limitations, but I see no reason to *require* their expiration. Req. 6 is entirely a restriction on applications, not the protocol, and so is not a matter for standardization. Req. 8 would be better phrased "The correlation mechanism shall be such that if a UA does not implement the correlation mechanism, or if it fails to discern a correlation specified by another UA, the resulting operation shall be a reasonable fall-back behavior." But that is just requiring reasonable upward-compatibility, which is implicit in all IETF standards. In regard to identifying conversation spaces, we need to pay attention to what we mean. Presumably, if dialog A is "in the same conversation space" as dialog B, then dialog B is also "in the same conversation space" as dialog A. More subtly, is this relationship transitive? That is, if we correlate A and B, and we correlate B and C, have we automatically correlated A and C? More treacherously, do these relationships change with time? Since the correlation mechanism is expected to operate not just at a single moment, but backward and forward in time (Req. 3), the natural assumption is that two dialogs are "in the same conversation space" through all time. But with a little work, we can construct sequences of interactions that cause a UA to create dialogs A and B to different endpoints, and then only later, the UA is forced to conclude that A and B are in the same communication space. But since the UA didn't know that fact at the time it created A and B, it may not have been able to tag them as "in the same communication space". One way to get out of that mess is to make the "in the same space" relationship abstract, and the UA never needs to actually know it. (The "References" header uses this escape; "related" is only truly known by an omniscient observer, and a UA never needs to know whether two dialogs are "related", it only needs to indicate to the omniscient observer that it knows at this moment that two dialogs are "related".) Another escape is to make "in the same communication space" entirely operational, to reduce it to "when initiating a dialog, the INVITE may indicate that this dialog is intended to be rendered 'in the same communication space' as one or more other specified dialogs". This is what the Join header does. Indeed, it seems that a workable solution to these problems is to create a header much like Join, say "With", which specifies the dialog identifiers of some other dialog which this dialog should be "rendered in the same communication space". This has the advantage that B2BUAs could mangle this header with exactly the same logic as they now use on Join and Replaces (simplifying deployment and eliminating the security issues). But disadvantage is that With might reference a dialog that has long since ended (e.g., 24 hours), in which case B2BUAs are unlikely to map it correctly. Dale _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
