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

From: Salvatore Loreto <[email-masked]>
Date: Thu, 16 Sep 2010 19:26:05 +0200

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 16 Sep 2010 19:32:35 +0200

Salvatore,

this is really good news, indeed. I believe it is now time to become 
operational on this interesting topic we just chartered. I hope people 
are going to use this document as a basis for fruitful discussions in 
the SPLICES WG!

Simon

Il 16/09/2010 19.26, Salvatore Loreto ha scritto:
> I have just submitted a new version of the "/Disaggregated Media in 
> the Session Initiation Protocol (SIP)/":
>
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices
>    

-- 
                             _\\|//_
                             ( 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~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Sep 2010 14:36:00 -0400

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

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 17 Sep 2010 13:08:58 +0200

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

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