I agree with Paul. I don't see why the requirements talk about 2 separate dialogs. The requirements should be formulated in terms of what we are trying to achieve, and we might then find that a single dialog solution will suffice. My understanding is that we are trying to achieve a call in which different media terminate on different devices. John > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of Paul Kyzivat > Sent: 11 December 2008 20:23 > To: Dale Worley > Cc: SIPPING > Subject: Re: Comments > ondraft-loreto-sipping-context-id-requirements-00 > > I still remain unconvinced that it is needful or reasonable > for party A > to expect it can ask party B to establish a correlation > between two dialogs. > > It becomes a very slippery slope. For instance once that has > happened, > if party B wants to transfer the "call", should it be expected to do > *two* transfers - one for each dialog? > > IMO this is a problem to be solved by the UA that wants the > correlation. > E.g. if A wants to have separate audio and video devices at > *its* end of > a dialog with B, then it is responsible for making that into > one dialog > for B. Then if B wants to transfer the call to C, it can do so using > normal means. A will be responsible for dealing with the > implications of > that, not B or C. > > In this case there clearly is some element that knows about the > correlation. But it is the same element that made the initial > decision > that a correlation is desirable. > > Thanks, > Paul > > Dale Worley wrote: > > On Wed, 2008-12-10 at 15:57 +0200, salvatore loreto wrote: > >>>> 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. > >>>> > >> [Sal] yes I agree that we have to discuss "when > correlation happens", > >> I do not have a strong opinion on this point, I think the > correlation > >> could happen at any point during the dialog establishment phase. > > > > The question is, that is, it might or might not be a > requirement: Does > > a dialog have to be specially marked during its > establishment in order > > for another, later, dialog to correlate with it? > > > >>>> 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".) > >>>> > >> [Sal] here you are already talking about a solution, where > I think we > >> should still continue to discuss the requirements > >> and the use case related to the requirements. > > > > Actually, I'm talking about another potential requirement: > If dialogs A > > and B are established, with no indication of correlation > between them, > > does it need to be possible for a dialog C to establish a > correlation > > with *both* A and B? (Which will presumably place all 3 > dialogs in the > > same communication space.) > > > > 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 > _______________________________________________ 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
