Re: [splices] draft-loreto-splices-disaggregated-media-00

[Lorenzo Miniero <[e-mail]>]

I read the draft and agree with Simon that is is a good starting point (especially from what concerns the overview on the state of the art) for the WG.

I agree with Paul that a centralized approach would be safer, from what I've understood by reading the draft, considering it would at the very least provide backward compatibility with exsting devices. Such an approach would nevertheless give some issues with respect to the correlation of media streams: for instance, which of my devices should take care of the IPTV stream coming from my peer? and first of all, how do I know which of the negotiated streams comes from the remote IPTV device? questions that are currently the basis for another IETF-based effort, the yet-to-be-born telepresence WG.

That said, I'm not at all against the concept of having a completely distributed approach, but figure 5 is probably a little confusing with respect to the aim of the draft: is Bob asking Alice to involve those three devices, or is Alice somehow telling Bob that she has three different devices that she wants to involve? Is a completely distributed scenario (as in figure 1) to be considered in devising the required mechanisms or do we need at least one controller? How can we prevent misuse of the mechanisms and ensure that devices are not involved improperly? (e.g. the summer cottage webcam) Are all the devices SIP-enabled or are we envisaging support for heterogeneous devices?

I think that we need to answer these questions and clarify the scenarios before delving into the specifics of the mechanisms themselves.

Lorenzo


On Thu, 16 Sep 2010 14:36:00 -0400
Paul Kyzivat <[e-mail]> wrote:

> I guess the point of the draft is to advocate for the mechanism in 
> section 4 / Figure 5. Right?
> 
> But ISTM that this doesn't address the use cases. Most of them start 
> with something like:
> 
>     Bob interacts, using his voice-only phone, with his PC and starts
>     live video stream to Laura's multimedia phone.
> 
> IOW, Bob's phone must still have some special behavior, to act as a 
> "controller" or "coordinator". Also, for this scenario to work, the 
> "smart" end (Alice's phone in most of the examples) also has to have 
> functionality to support this. The rest of Bob's devices also need 
> special behavior too, to interact with Bob's phone, taking instructions 
> to play in this environment.
> 
> I guess the minimum those devices might need is the ability to support 
> REFER. But its more than that - they need to know what to do with a 
> REFER that isn't replacing an existing call - what media to involve, 
> etc. That isn't something that can be expected by default of a device, 
> like a PC, that has sip functionality.
> 
> I think this approach is really much like the 3pcc approach, except that 
> it has the controller reside with the *other* participant.
> 
> One of the other problems with the 3pcc approach is that the controller 
> can't get out of the call unless it can transfer its responsibilities to 
> some other controller. (I guess there could easily be cases where there 
> is only one device with controller capability that the user controls.)
> 
> A hybrid solution could be that if the user needs to take his controller 
> out of the call, and the other participant in the call has controller 
> capability, then the user could transfer the controller responsibilities 
> to the other user, thus turning the call from figure 2 to figure 5.
> 
> However, I'm not convinced that is even an important use case. If you 
> have a device smart enough to act as controller to set up figure 5, then 
> I think its smart enough to act as a controller in one of the 
> centralized approaches. And I have difficulty thinking of cases where 
> you need to take that device out of the call and yet still have more 
> than one device remaining that need to be coordinated.
> 
> IMO the centralized approaches are much preferable. A key point is that 
> they only involve one end. IOW, if *I* want to involve multiple devices 
> in my call, I can do so without a requirement for the other participant 
> in the call to know anything about that. That seems critical, because 
> there probably won't be a lot of these devices (at least at first) so it 
> better not require a pair to be useful.
> 
> The harder question (and the one that this group could address) is 
> *which* coordination mechanism(s) to define.
> 
> In principle it isn't required that there be only one. You could use one 
> mechanism for your devices, and I could use a different one for mine and 
> we could still communicate just fine. But that would lead to all sorts 
> of interop issues among devices on a single end. So I think there should 
> at least be one preferred to implement mechanism.
> 
> 	Thanks,
> 	Paul
> 
> On 9/16/2010 1:26 PM, Salvatore Loreto wrote:
> >   Hi there,
> >
> > in order to continue the "/loosely coupled sip devices/" discussion ,
> > I have just submitted a new version of the "/Disaggregated Media in the
> > Session Initiation Protocol (SIP)/":
> >
> > http://datatracker.ietf.org/doc/draft-loreto-splices-disaggregated-media/
> >
> > The previous version of the draft was discussed in DISPATCH WG.
> >
> > comments and feedback are very welcome
> >
> > cheers
> > /Sal
> >
> > --
> > Salvatore Loreto
> > www.sloreto.com
> >
> >
> >
> > _______________________________________________
> > splices mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/splices
> _______________________________________________
> splices mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/splices
> 


-- 
Lorenzo Miniero, Junior Researcher
Dipartimento di Informatica e Sistemistica
Universita' degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: [phone] - Fax: [phone]
Email: [e-mail]