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
