Subject: [Sipping] comments on draft-loreto-sipping-context-id-requirements-01.txt

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 22 Mar 2009 20:55:56 -0400

Thanks for continuing to work this, Salvatore.

My main comment, as others have commented, is that the draft provides a 
great set of use cases. However, it makes the fundamental assumption 
that the right way to solve this is by having multiple dialogs from user 
A to user B, and then have them correlated. I am *far* from convinced 
this is the right solution.

So, focusing strictly on requirements, I'd like to see this document 
retitled to something like, "Requirements for Supporting Disaggregated 
Media", and keep the use cases, except delete the bits that suggest that 
the problem is multiple dialogs. For example, in section 2.1, the first 
two paragraphs are good, but the last two *assume* the multiple dialog 
solution.

Other suggestions for similar use cases:

* voice/video from a deskphone and application sharing from PC
* voice from a deskphone and video to/from a TV attached to a set top 
box with a camera
* the UI for the call on a mobile phone but the audio coming out of a 
speakerphone in a room

There are lots more. I think the draft just should enumerate these.

The requirement, then, is a mechanism which allows these use cases. I 
personally think that the solution should be *completely invisible* to 
the far end of the call. In all cases, all of the various devices under 
Alice's control (where Alice is the one with a multiplicity of devices) 
need some kind of enhancement to make this work; I would very much like 
to avoid the need for Bob to do *anything* to make this work. The reason 
is simple: its much, much easier for a user to upgrade (or their provier 
to upgrade) the devices under their control to get a feature that 
benefits them, than it is to require *everyone else* to upgrade in order 
to get a feature to work which benefits me.

The document has this requiremnt:

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.

this is not nearly strong enough. I think the real requirement is:

REQ3: The mechanism should not require any changes to the far side of 
the session.

I also don't think 3pcc is a particularly good solution either; besides 
the issues raised in the threads about requiring one device to be 
controller and the resulting complications, it also results in a really 
suboptimal user experience because the slave phones think this is just a 
normal call when its not. As a simple example, the caller ID on one of 
the slave phones would probably show the controller and not the far end.

As another example, consider a PC doing video and audio on the 
hardphone. What if the hardphone can also do video, and the user hits 
the video button on the phone? Most likely this creates two video 
streams. Ugh. Indeed, the hardphone would ideally indicate that there 
already WAS video in progress, but on a PC. All of this means you can't 
really just 'fool' the slave phone into sending media somewhere - you 
really want it to be much smarter about this situation and be well aware 
that there is disaggregated media.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Mar 2009 10:13:36 -0400

I largely agree with Jonathan.

I even agree that an *ideal* solution will have the aggregated devices 
aware that the aggregation is present. But I think it is also important 
to be able to create such aggregations where only a subset of the 
aggregated devices are aware of the aggregation. This is just a 
recognition of the need to accommodate existing devices. It may be 
suboptimal, but still more optimal than not having the aggregation at 
all. For instance its easy to imagine this being orchestrated from one 
"smart" device and a variety of "dumb" devices. So I see 3pcc as *one* 
implementation, for which no additional standardization work is 
required. There could be additional standardization work to communicate 
the aggregation details among the cooperating devices.

Just in case it isn't obvious, the aggregation can occur at both ends of 
the call too. That is all the more reason for aggregation at one end to 
be hidden from the other end. The media may be disaggregated in 
different ways at the two ends. If each end must be aware of what is 
going on at the other end, then this becomes an O(n^2) problem.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Mar 2009 01:15:00 +0000

I entirely agree with what Jonathan and Paul say. Although I raised 3PCC
as one alternative, I agree it has drawbacks and I would be interested
to hear other proposed solutions. But first let's get the requirements
stated at the right level.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 23 March 2009 14:14
> To: Jonathan Rosenberg
> Cc: IETF Sipping List
> Subject: Re: [Sipping] comments 
> ondraft-loreto-sipping-context-id-requirements-01.txt
> 
> _______________________________________________
> 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
>