Subject: Re: [Sipping] I-D Action:draft-loreto-sipping-context-id-requirements-01.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2008 09:46:20 -0400

IMO this is a big improvement over the prior version.
It focuses much more on the features desired than the mechanism for 
realizing those features.

BUT it still contains an assumption that the solution will involve 
multiple dialogs between the originating and terminating parties, with a 
need for explicit correlation between the dialogs at both ends. IMO 
there are better solutions that don't require that.

If that assumption can be removed from this draft, so we can just agree 
on the desired user experience before getting into details of 
implementation, then I would wholeheartedly support this draft. I think 
these *are* the kinds of features that can make sip compelling.

When it is stripped back to that level, this might be better dealt with 
in the bliss wg.

	Thanks,
	Paul
_______________________________________________
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: Salvatore Loreto <[email-masked]>
Date: Mon, 20 Oct 2008 17:47:28 +0300

Hi Paul and all,

thanks for your comments.

We have rewritten the draft 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.

The draft now lists 5 possible use cases that need a similar feature for 
a distributed User Agent Client,
plus one use case for a distributed User Agent Server to show that the 
feature could eventually work also in this scenario.

we really have tried to avoid any pre assumption, focusing only on the 
desired user experience.
without focusing on any solution.
The use cases have been drafted only for the sake of showing the need of 
a similar feature in a clear way.

However we are ready to continue to work on it, if it is necessary.
So if you can explain better your concern it would help.

thank in advance
Sal

Paul Kyzivat wrote:
> multiple dialogs between the originating and terminating parties, with 
> a need for explicit correlation between the dialogs at both ends. IMO 
> If that assumption can be removed from this draft, so we can just 
> agree on the desired user experience before getting into details of 
> implementation, then I would wholeheartedly support this draft. I 
> think these *are* the kinds of features that can make sip compelling.
>
> When it is stripped back to that level, this might be better dealt 
> with in the bliss wg.
>
> Thanks,
> Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Oct 2008 12:44:41 -0400

> without focusing on any solution.

I appreciate that. But some assumptions about the solution still crept 
in. Its essentially the same assumption in all cases, so I will only 
give one example. In 3.1:

    Laura decides to answer the Bob's session invitation by establishing
    a voice session with Bob using the desk phone and the video session
    using her multimedia phone.

I like the above.

    Two SIP dialogs need to be established:
    one between Bob's UA and Laura's desk phone and one between Bob's UA
    and Laura's multimedia phone.

This is one way to accomplish the establishment of the two media 
sessions. But its not the only way. (Or IMO the best way.)

An alternative is for Laura's multimedia phone to establish a dialog 
with her desk phone, with a voice session, and then to complete the 
establishment of a dialog with Bob's UA with both the voice session from 
the desk phone and a video session terminated on the multimedia phone.

The result is that there is indeed correlation between two dialogs, but 
that correlation, or the existence of multiple dialogs, need not be 
communicated to Bob's UA. It doesn't even need to be signaled to Laura's 
desk phone. The correlation is simply known within Laura's multimedia 
phone. Ultimately Bob's UA has one dialog with two media streams that 
happen to terminate on different devices.

I'd prefer to see the requirements be independent of the implementation. 
Then we can weigh the pros and cons of an implementation such as I am 
suggesting, and one like you seem to be implying where there are 
multiple dialogs e2e that must be correlated.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 22 Oct 2008 13:58:32 +0300

Paul Kyzivat wrote:
...
> establishment of a dialog with Bob's UA with both the voice session 
> from the desk phone and a video session terminated on the multimedia 
> phone.
>
> The result is that there is indeed correlation between two dialogs, 
> but that correlation, or the existence of multiple dialogs, need not 
> be communicated to Bob's UA. It doesn't even need to be signaled to 
> Laura's desk phone. The correlation is simply known within Laura's 
> multimedia phone. Ultimately Bob's UA has one dialog with two media 
> streams that happen to terminate on different devices.
I have to say that you are right, there are several ways to accomplish 
the establishment of the two media session in this case, but it is due 
to the fact that Laura
has a multimedia phone. In fact I don't think it would be possible mean 
if she had instead two phones each of the one able to handle only one 
media out of the two.

Having said that,
I fully agree with you that the requirements have to be independent of 
the implementations, and I think that the way we have written them is 
implementation independent.
In fact the requirements don't talk about e2e dialogs, but dialog in 
general:

   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.

IMO the solution you have described does not contradict any of the above 
requirements. Please correct me, if I am wrong.

Thanks
Sal

>
> I'd prefer to see the requirements be independent of the 
> implementation. Then we can weigh the pros and cons of an 
> implementation such as I am suggesting, and one like you seem to be 
> implying where there are multiple dialogs e2e that must be correlated.
>
>     Thanks,
>     Paul
>
>> The use cases have been drafted only for the sake of showing the need 
>> of a similar feature in a clear way.
>>
>>> multiple dialogs between the originating and terminating parties, 
>>> with a need for explicit correlation between the dialogs at both 
>>> ends. IMO there are better solutions that don't require that.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2008 10:05:45 -0400

comments inline.

> if she had instead two phones each of the one able to handle only one 

Well, *something* must have the intelligence to decide that coordinating 
two devices for the same call is possible and desirable, and then 
arrange for it to be done. If you just had two single media devices with 
no awareness of each other and no intelligence elsewhere to set it up 
then it won't happen.

If that intelligence *is* there, then it doesn't matter that each device 
only supports one medium.

And I think its key in this that the examples are all cases where one 
"end" of the call decides to partition the call among multiple devices 
at *its* end. Its not a case of Bob deciding to join two of Laura's 
devices, or visa versa.

So the key part of my point is that it isn't going to be necessary (or 
even desirable) for the end that is correlating two dialogs to 
communicate that correlation to the other end. I know you don't come out 
and say that is what you are looking for, but I get the sense that it is.

>      mechanism should not keep them from trying to handle the SIP

OK. If we restrict our discussion to just the requirements themselves, 
then I think we are closer to agreement. But the examples at least 
suggest more.

> requirements. Please correct me, if I am wrong.

I guess reasonable people might differ on that. I think it *could* be 
viewed as being consistent with the above requirements. But it might 
also not be viewed as a sufficient realization of those requirements 
because it doesn't support correlation between arbitrary dialogs.

Since the approach I suggest doesn't require anything new be added to 
the protocol we already have, there wouldn't be any reason to progress a 
set of requirements to enable that kind of development.

IMO, if Laura wants to use two of her devices in a single session, then 
she should not expect to trouble Bob with that - it is something to be 
worked out locally among her devices. That way, Bob still sees one 
session. If he wants to transfer it, conference it, put it on hold, etc. 
then he need only deal with one session. The complexities of 
multiplexing that across multiple dialogs at Laura's end will then be 
dealt with by Laura.

(Of course, if Bob wants to establish sessions from his UA to two of 
Laura's devices, and treat them as one session, then it is also free to 
do that. Again it doesn't require the signaling of any correlation.)

	Thanks,
	Paul