Subject: Re: [Sipping] Comments on draft-loreto-sipping-context-id-requirements-00

From: [email-masked]
Date: Mon, 8 Dec 2008 11:35:33 -0500 (EST)

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Krishna Prasad Kalluri" <[email-masked]>
Date: Mon, 8 Dec 2008 21:52:32 +0100

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: [email-masked] genom [email-masked]
Skickat: må 2008-12-08 17:35
Till: [email-masked]
Ämne: Re: [Sipping] Comments ondraft-loreto-sipping-context-id-requirements-00

Dale

---

From: salvatore loreto <[email-masked]>
Date: Tue, 09 Dec 2008 12:14:46 +0200

Hi Dale,

thank for your comments,
however as Krishna has pointed out in his previous mail,
in the last version of the draft 
(http://tools.ietf.org/id/draft-loreto-sipping-context-id-requirements-01.txt),
the one I presented in Minneapolis, there are only three requirements.

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:

   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.

   REQ2  The state information associated to the correlation among a set
      of SIP dialogs must expire (i.e., can be discarded) when the last
      of the SIP dialogs is terminated.

   REQ3  UAs that do not implement the correlation mechanism and, thus,
      do not understand the correlation information they received should
      be able to handle the individual SIP dialogs that were supposed to
      be correlated as well as possible.  That is, the correlation
      mechanism should not keep them from trying to handle the SIP
      dialogs.

However during the discussion was clear that there are other drafts that 
are looking for a similar
"correlation mechanism", but with slightly different requirements!

I am perfectly aware that the above requirements do not cover all the 
use cases that different
people have in mind, and that the requirements need to be 
expanded/rephrased etc. etc.
so I am keen for working with all of you to lists all the different 
requirements and use cases, in order to figure out
the semantics of all possible use-cases and then analyse all of them in 
order to understand how to proceed.

/Sal

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Dec 2008 09:41:46 -0500

Dale,

> case, there's no SDP to be revised to include an audio or video

Well, since the draft only talks about correlating dialogs, the issue 
with MESSAGE only comes when using MESSAGE in-dialog.

While it isn't *forbidden* to use MESSAGE in a dialog, that technique 
was rejected by the WG for session mode IM. Also, the last I knew, at 
least Microsoft's use of MESSAGE in-dialog also used a special m-line in 
SDP to negotiate doing so.

Establishing a dialog without media, to be used for exchanging MESSAGE 
hasn't been formally defined. It would be problematic - some kind of 
signaling would be needed to indicate that the intent is to exchange 
MESSAGEs. If you have that, then it could probably be used to combine 
the media. Certainly if you have a dialog with no media you can make 
another offer to add voice or video.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 09 Dec 2008 15:42:56 -0500

> another offer to add voice or video.

But if you tagged each of a long series of out-of-dialog MESSAGE
requests with the same context-id, they'd all get displayed in the same
communication context at the recipient, even if each MESSAGE had a
unique call-id.  (In this, I'm modeling such a MESSAGE as "a dialog of
one request", which I think is more or less implicit in SIP.)

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 09 Dec 2008 15:50:51 -0500

> 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?

> More treacherously, do these relationships change with time?  [...deleted...]
> But with a little work, we can construct sequences

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Tue, 09 Dec 2008 15:52:55 -0500

> one request", which I think is more or less implicit in SIP.)

Ah, yes...  In the -01 version, since you can't correlate a dialog with
a dialog that is terminated, you can't use the trick of forcing each
MESSAGE to be correlated with each other MESSAGE, since their "dialogs"
last only an instant.

Dale

---

From: salvatore loreto <[email-masked]>
Date: Wed, 10 Dec 2008 15:57:55 +0200

Hi Dale,

see my comments in line

/Sal

>> 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.
>> space" as dialog A.
[Sal] the relation is for sure "reflexive" if dialog A is correlate with 
dialog B, then dialog B is correlate with dialog A.
>>   More subtly, is this relationship transitive?
[Sal] I am tempted to say yes, the relationship is transitive!
however I can also imagine a scenario where there are different kind of 
correlation:
so if A and B are correlate with a correlation type X and B and C are 
correlate with a correlation type Y,
where the correlation type X is different from the correlation type Y,
then A and C are not automatically correlate.
But maybe this is something to complicate to implement and I don't know 
it is useful at all.
>> More treacherously, do these relationships change with time?  [...deleted...]
[Sal] I have never thought of a similar possibility
>> 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.

>> what the Join header does.
[Sal] yes Join header does but with a different and specific semantic.

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 11 Dec 2008 15:06:37 -0500

On Wed, 2008-12-10 at 15:57 +0200, salvatore loreto wrote:
> 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?

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 11 Dec 2008 15:22:53 -0500

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 11 Dec 2008 20:52:49 +0000

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 11 December 2008 20:23
> To: Dale Worley
> Cc: SIPPING
> Subject: Re: [Sipping] Comments 
> ondraft-loreto-sipping-context-id-requirements-00
>

---

From: salvatore loreto <[email-masked]>
Date: Fri, 19 Dec 2008 16:45:05 +0200

Dale Worley wrote:

...<snip>
> for another, later, dialog to correlate with it?
I don't think it might be a requirement, it seems to be more a technical 
solution issue
the requirement have only to say that
"it should be possible for a dialog, no matter in what stage it is, to 
be correlate
with another one."
Maybe we have to phrase it in a better way. Please feel free to suggest 
a text for it!

...<snip>
> same communication space.)
Now I got it.

actually both the Req 1 the one in the 
draft-loreto-sipping-context-id-requirements-01.txt

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.

and the one in draft-kaplan-sip-session-id-01.txt

 REQ1: It must be possible to identify a set of dialogs which have a
   direct correlation with each other such that they represent the same  
   SIP session, with as high a probability as possible. 

talk about the possibility to establish a correlation between a new dialog
and one or more existing dialogs, no matter it there is already some 
correlation among them or not.
Do you think we should be more explicit on this point?

Sal

---

From: salvatore loreto <[email-masked]>
Date: Fri, 19 Dec 2008 17:57:41 +0200

Hi Paul, John and all,

I agree that party A could use 3pcc to making transparent for party B 
the fact that it is using separate devices for different media, and
then making everything into one dialog for B;
however there could be situation, and indeed there are use cases where 
it would be preferable not using a centralized and heavy mechanism as
3pcc but instead having something more distributed and lighter.

About your concern on what happens if party B wants to transfer the 
"call", in the case where party A asked party B to establish a correlation
between two dialogs, my first answer is that yes it should be expected 
to do *two* transfer - one for each dialog, and I don't see any
problem in this. Of course I can be wrong in this, and probably I am, as 
usual.

Thanks
Sal

Paul Kyzivat wrote:
> 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.
>
> 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.
>
>>> I do not have a strong opinion on this point, I think the 
>>> correlation could happen at any point during the dialog 
>>> establishment phase.
>>
>>> [Sal] here you are already talking about a solution, where I think 
>>> we should still continue to discuss the requirements

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 19 Dec 2008 16:47:43 +0000

Sal, 

> [mailto:[email-masked]] On Behalf Of salvatore loreto
> Sent: 19 December 2008 15:58
> To: Paul Kyzivat
> Cc: SIPPING
[JRE] 3PCC would be one possibility. Non-SIP communication between the
two devices might be another (depending on whether rendez-vous
capability of SIP is necessary or not for this purpose).

> problem in this. Of course I can be wrong in this, and 
[JRE] I see this as a huge problem, expecting the remote endpoint to
undertake complex procedures for something that benefits the other end.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Dec 2008 13:37:53 -0500

> 3pcc but instead having something more distributed and lighter.

IMO the 3pcc mechanism isn't so heavy weight, and the correlation will 
introduce some extra weight as well.

Where there is an existing mechanism that will solve the problem, I 
think you have to make a strong case for why we need to introduce 
additional machinery.

Its doubly bad here, because the burden of the correlation falls on UA 
that has no need for correlation. This also makes adoption more 
difficult. If the 3pcc mechanism is used, only the device that wants to 
exploit another device to extend its call need implement it. Neither the 
subordinate device nor the other party need do anything special.

With the correlation approach, you can only use the combination of 
devices if all the UAs support it.

> problem in this. Of course I can be wrong in this, and probably I am, as 

This is part of the extra "weight" of this new mechanism.
All of a sudden B has to do a lot more work to handle the transfer.

	Thanks,
	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 22 Dec 2008 17:12:07 -0500

> Do you think we should be more explicit on this point?

The first question is to come to a clearer understanding in our own
minds what capabilities we want the mechanism to have.  After that, we
can write clearly what the requirements are.

In this case, the following two requirements may be quite different in
regard to the solutions that they admit:

Req A:  It must be possible, when establishing a dialog, to specify that
it be correlated with one or more already existing dialogs, which
dialogs, at the time they were created, did not need to specify that
they might be correlated with in the future.

Req B:  It must be possible, when establishing a dialog, to specify that
it be correlated with one or more already existing dialogs, which
dialogs, at the time they were created, may be required to have
specified that they might be correlated with in the future.

Dale