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

From: Salvatore Loreto <[email-masked]>
Date: Thu, 18 Nov 2010 16:34:17 +0200

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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/splices

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 26 Nov 2010 12:10:16 +0100

I still don't like the fact that there is impact on Bob's UA. Even though that impact might only be session correlation, this could be quite complex. It sounds to me like Bob's UA, on deciding that two SIP dialogs relate to the same session, must somehow merge the two session descriptions (SDP). In the simple case, where one session is audio only and the other is video only, it might be relatively simple, e.g., an assumption that the two need to be lip-synched could be made. But we surely would need to deal with more complex cases, e.g., an additional video stream for presentations, floor control of the presentation stream or other streams, multiple audio and/or video channels for telepresence, grouped media spanning more than one contributing session description, etc.. Multimedia SIP UAs will have no incentive to implement extensions to cover session correlation and merging, so this will constrain interoperability.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Salvatore Loreto
> Sent: 18 November 2010 14:34
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [splices] draft-loreto-splices-disaggregated-media-00
> 
> Hi Paul,
> 
> thanks for the comments,
> see my answers in line.
> 
>

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 29 Nov 2010 17:23:01 +0200

Hi John,

On 11/26/10 1:10 PM, Elwell, John wrote:
> I still don't like the fact that there is impact on Bob's UA.
supporting new features most likely implies an impact on the UA(s) that 
wants support them.
anyway the features are optional!
> Even though that impact might only be session correlation, this could be quite complex.
if we are able to standardize a good and hopefully general session-id 
mechanism,
then the impact coming from SPLICE is really minimal.

/Sal

> It sounds to me like Bob's UA, on deciding that two SIP dialogs relate to the same session, must somehow merge the two session descriptions (SDP). In the simple case, where one session is audio only and the other is video only, it might be relatively simple, e.g., an assumption that the two need to be lip-synched could be made. But we surely would need to deal with more complex cases, e.g., an additional video stream for presentations, floor control of the presentation stream or other streams, multiple audio and/or video channels for telepresence, grouped media spanning more than one contributing session description, etc.. Multimedia SIP UAs will have no incentive to implement extensions to cover session correlation and merging, so this will constrain interoperability.
>
> John

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 29 Nov 2010 17:00:14 +0100

I also think that once we're done with the session-is issue, things in 
SPLICES can proceed really smoothly. Let's keep in mind that this same 
discussion is taking place in DISPATCH, also. Interested people should 
have a look at the thread over there.

Simon (as an individual)

Il 29/11/2010 16:23, Salvatore Loreto ha scritto:
> supporting new features most likely implies an impact on the UA(s) 
> that wants support them.
>> It sounds to me like Bob's UA, on deciding that two SIP dialogs 
>> relate to the same session, must somehow merge the two session 
>> descriptions (SDP). In the simple case, where one session is audio 
>> only and the other is video only, it might be relatively simple, 
>> e.g., an assumption that the two need to be lip-synched could be 
>> made. But we surely would need to deal with more complex cases, e.g., 
>> an additional video stream for presentations, floor control of the 
>> presentation stream or other streams, multiple audio and/or video 
>> channels for telepresence, grouped media spanning more than one 
>> contributing session description, etc.. Multimedia SIP UAs will have 
>> no incentive to implement extensions to cover session correlation and 
>> merging, so this will constrain interoperability.
>>
>> John
>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/