On Tue, 2008-12-09 at 12:14 +0200, salvatore loreto wrote: > In fact we have heavily rewritten the last version focusing only on the > problem space related to how > logically correlate multiple SIP dialogs that relate to the same > multimedia session, > without any assumption on the desired mechanism: OK, I was out-of-date there. One thing I notice is that the requirement to be able to correlate with past dialogs is removed, which means that you can't support some of the use cases in the -00 draft. Have those become unimportant? > REQ1 It must be possible to correlate an already existing dialog or > dialogs with a new dialog or dialogs as relating to the same media > session. The following questions remain: > 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 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? [...deleted...] > 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. 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
