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

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
> splices@ietf.org
> https://www.ietf.org/mailman/listinfo/splices