Re: comments ondraft-loreto-sipping-context-id-requirements-01.txt

["Elwell, John" <john.elwell@xxxxxxxxxxxxxxxxxxxxxx>]

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