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

Hi Paul,

thanks for the comments,
see my answers in line.

On 9/16/10 9:36 PM, Paul Kyzivat wrote:
> I guess the point of the draft is to advocate for the mechanism in
> section 4 / Figure 5. Right?

more precisely the draft advocates a scenario where none of the nodes 
can act as a "controller".

In Fig.5 (on section 
http://tools.ietf.org/html/draft-loreto-splices-disaggregated-media-00#page-11 
)
describes only one end (Alice) as distributed, but the idea can be 
generalized where both the ends
are distributed.

> 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.

in loosely coupled scenarios, the entity acting as the controller could 
be the human user.
That is, the human user (Bob) could know he has two devices involved in 
the same call
and there two sessions, one with a phone and another with the softclient 
in the laptop.
Maybe we do not have lip synchronization and things like that,
but as long as the media streams are loosely coupled, the session could 
be as well.

> 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.

The ability to support REFER can help,
but as you have pointed out there would be the need to standardize a 
different usage for it.

lets consider the following strawman  scenario where
Alice has three UAs and
Bob has only one.

1) Alice UA-1  starts a voice session with  Bobs UA.
this session contains a supervisor-id of some kind that will be used in 
potential further
sessions between Alice and Bob, either started from Bob to Alice or 
again from Alice to Bob.

2) Alice adds video.
Alice UA-1 sends a REFER to Alice UA-2 capable of video.
The REFER points to Bob's address.
The same REFER also include the above supervisor-id.

3) Alice UA-2 uses REFER information to send the INVITE#2 towards Bob.

4) Bob's session supervisor extracts the supervisor ID from session#2 
and direct this session
locally to the already running SIP session#1 application, which expands 
its user window with the media
of session#2

> I think this approach is really much like the 3pcc approach, except that
> it has the controller reside with the *other* participant.

not really,
it is totally different from the 3pcc approach,
in fact it is a distributed approach where neither ends need a 
centralize controller
(e.g. a master device)

> 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.

This does not work in the case both participants use several UAs.

> 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.

Receiving side does not require to act as controller.
In the approach described in the above strawman the receiving side only 
needs
to look up the communication context reference in the INVITE#2.

>   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.

not to put any requirements of the other participant would be ideal.
In reality what we can do is to minimize the requirements on the other 
participant.
The strawman solution above the requirement would be just implement
a supervision session to check if the incoming invite can be correlated to
an existing session or not.

> The harder question (and the one that this group could address) is
> *which* coordination mechanism(s) to define.

it may be to see what people think about the possibility that the entity
acting as the controller is just the human user.

cheers
/Sal

> 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