Subject: [dispatch] Charter Proposal for Disaggregated Media

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Sep 2009 13:51:51 +0300

Hi there,

below is a charter proposal for a WG on Disaggregated Media.

All comments, thoughts, feedbacks are very welcome!

cheers
Sal

Disaggregated Media WG Charter
------------------------------- 
Disaggregated media refers to the ability for a user to create a
multimedia session combining different media streams, coming from
different devices under his or her control, so that they are treated
by the far end of the session as a single media session.

Generally, a given participant uses a single device to establish (or
participate in) a given multimedia session.  Consequently, the SIP
signaling to manage the multimedia session and the actual media
streams are typically co-located in the same device.  In scenarios
involving disaggregated media, a user wants to establish a single
multimedia session combining different media streams coming from
different devices under his or her control.  This creates a need to
coordinate the exchange of the those media streams within the media
session.

The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate
the different devices under his control to involve them in the call.
The different devices can communicate with one another using Mbus 
messages, and then let only one device, a call control engine, to 
initiate, manage and terminate call control relations to other SIP endpoints. 
All the different user's devices need to support the Mbus protocol.

The Megaco [RFC3525] protocol can be used in a disaggregated media 
scenario to let one of the user's devices act as a Media Gateway Controller,
coordinating all the other devices under the user's control, which in this case
will act as Media Gateways. In this case all the different user's devices 
need to support the Megaco protocol.

The SIP protocol provides 3pcc [RFC3725] as a possible mechanism
to coordinate the exchange of media streams coming from different 
devices under the control of the same user, in the case at least 
one among the different devices under his control supports this
mechanism and is able to become a Controller for the other in the call. 

All the existing mechanisms only cover a subset of the interesting scenarios 
that involve disaggregated media. Scenarios not covered by existing mechanisms 
include the loosely-coupled one where none of the nodes can act as a controller
because it does not support the necessary functionality or because it will not
participate in the whole session.

The objective of the proposed working group is to develop a framework
for Disaggregated Media that include both improvements on existing 
mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms
like a loosely coupled mechanism that does not require the implementation 
of complex logic on any of the terminals.

Specifically, the proposed working group will develop the following
deliverables: 
1. A framework document describing key design considerations for Disaggregated 
   mediamechanism.
2. A specification for a loosely couple mechanism.
3. One or more specifications to improve existing mechanism to coordinate
   disaggregated media.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Sep 2009 11:32:12 -0400

I agree with the utility of such work. Comments inline.

Salvatore Loreto wrote:
> ------------------------------- Disaggregated media refers to the 
> ability for a user to create a
> initiate, manage and terminate call control relations to other SIP 
> endpoints. All the different user's devices need to support the Mbus 
> protocol.
> 
> will act as Media Gateways. In this case all the different user's 
> devices need to support the Megaco protocol.
> 
> devices under the control of the same user, in the case at least one 
> among the different devices under his control supports this
> All the existing mechanisms only cover a subset of the interesting 
> scenarios that involve disaggregated media. Scenarios not covered by 
> existing mechanisms include the loosely-coupled one where none of the 
> nodes can act as a controller
> because it does not support the necessary functionality or because it 
> will not participate in the whole session.

I don't understand the above. The disaggregated multimedia session will 
not be established unless *something* takes the initiative to establish 
it. IMO that thing, whatever it is, is acting as a "controller".

The mechanism you have proposed before distributes the "controller" 
functionality across multiple nodes. There is something that causes a 
new stream to be established as a separate sip session and causes that 
to announce correlation with some other session. And then there is are 
the devices at the far end, that maintain the correlation and do 
required maintenance of the correlation as changes happen.

Can you provide more definition of what you mean by "loosely coupled" 
while recognizing that something needs to know enough to do the 
initiation and maintenance of the correlation?

> like a loosely coupled mechanism that does not require the 
> implementation of complex logic on any of the terminals.

I would argue that it is premature to assert that new mechanisms are 
required.

> deliverables: 1. A framework document describing key design 
> considerations for Disaggregated   mediamechanism.

> 3. One or more specifications to improve existing mechanism to coordinate

Are both (2) and (3) *specifications*? Or is (2) a requirements document 
that is then satisfied by (3)?

If (2) is requirements, then this makes sense to me, though it might be 
possible to combine that with (1). If both (2) and (3) are mechanism 
specs then I don't get it.

	Thanks,
	Paul

---

From: Roni Even <[email-masked]>
Date: Mon, 21 Sep 2009 19:23:44 +0300

Hi,
What is the relation between this proposal and the SIP and XMPP proposal.
To me it looks like both are trying to combine two separate call legs to be
as one and have similar requirements.

Roni Even

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Salvatore Loreto
> Sent: Monday, September 21, 2009 1:52 PM
> To: IETF Dispatch
> Cc: Gonzalo Camarillo
> Subject: [dispatch] Charter Proposal for Disaggregated Media
> 
> Hi there,
> 
> endpoints.
> scenarios
> implementation
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Sep 2009 19:38:59 +0300

Hi Roni,

actually there isn't any relation between this two proposals, each of 
them has started from a different use case.

however if you consider XMPP as a XML streaming, then combining SIP and 
XMPP can be considered as particular case where
"a user wants to establish a single multimedia session combining 
different media streams coming from
different devices under his or her control."

/Sal

---

From: Roni Even <[email-masked]>
Date: Mon, 21 Sep 2009 19:55:46 +0300

Hi,
This is what I meant, you can look at XMPP and the voice streams as two
media streams that you want to handle as one multimedia session.
Roni Even

> From: Salvatore Loreto [mailto:[email-masked]]
> Sent: Monday, September 21, 2009 7:39 PM
> To: Roni Even
> Cc: 'IETF Dispatch'; 'Gonzalo Camarillo'
> Subject: Re: [dispatch] Charter Proposal for Disaggregated Media and
> combining SIP and XMPP
> 
> Hi Roni,
> 
> >> coordinating all the other devices under the user's control, which
> in
> >> this case

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 23 Sep 2009 17:08:58 +0300

Hi Paul,

thanks for the comments, please see my answers in line

cheers
Sal

> I agree with the utility of such work. Comments inline.
<snip>
> I don't understand the above. The disaggregated multimedia session 
> will not be established unless *something* takes the initiative to 
> establish it. IMO that thing, whatever it is, is acting as a 
> "controller".
>
the "loosely couple control" is a scenario where you can easily remove, 
at any point, any of several devices involved in the conversation, and 
the other end of the conversation will remain unaffected.

easily and at any point mean that you do not need to start a complicate 
mechanism before you can remove the device (e.g. you do not need to 
choose a new controller and transfer the control to it)

of course loosely couple control still needs some sort of control, you 
are right.
However the control could be easily a "distributed" control with a 
minimal amount of information, where, for example, each device involved 
in the conversation only knows the list of all the other devices 
involved in the conversation, but it does not need to know the full 
state "information" related to the dialog that each device has with the 
far end of the conversation.
> I would argue that it is premature to assert that new mechanisms are 
right, that is something the community has to decide.
> Are both (2) and (3) *specifications*? Or is (2) a requirements 
> document that is then satisfied by (3)?
yes (1) and (2) can be combined and then eventually produce a new actual 
mechanism.
>
> If (2) is requirements, then this makes sense to me, though it might 
> be possible to combine that with (1). If both (2) and (3) are 
> mechanism specs then I don't get it.
>
>     Thanks,
>     Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 24 Sep 2009 16:26:46 -0500

I support this work, and as we have seen in the past, with multiple proposals,
the need is real.

The charter generaly looks OK to me. 

I am personally much more interested in the "loosely coupled" aspect to this,
as opposed to the MBUS/MEGACO/3PCC aspects, but I don't object to the 
group covering both.

-Francois

> -----Original Message-----
From: Salvatore Loreto <salvatore.loreto at ericsson.com>
To: IETF Dispatch <dispatch at ietf.org>
Cc: Gonzalo Camarillo <gonzalo.camarillo at ericsson.com>
Date: Mon, 21 Sep 2009 13:51:51 +0300
Hi there,

cheers
Sal

The Message Bus (Mbus) [RFC3259] can be used by an user to coordinate
the different devices under his control to involve them in the call.
The different devices can communicate with one another using Mbus messages, and then let only one device, a call control engine, to initiate, manage and terminate call control relations to other SIP endpoints. All the different user's devices need to support the Mbus protocol.

The Megaco [RFC3525] protocol can be used in a disaggregated media scenario to let one of the user's devices act as a Media Gateway Controller,
coordinating all the other devices under the user's control, which in this case
will act as Media Gateways. In this case all the different user's devices need to support the Megaco protocol.

The SIP protocol provides 3pcc [RFC3725] as a possible mechanism
to coordinate the exchange of media streams coming from different devices under the control of the same user, in the case at least one among the different devices under his control supports this mechanism and is able to become a Controller for the other in the call.

All the existing mechanisms only cover a subset of the interesting scenarios that involve disaggregated media. Scenarios not covered by existing mechanisms include the loosely-coupled one where none of the nodes can act as a controller
because it does not support the necessary functionality or because it will not
participate in the whole session.

The objective of the proposed working group is to develop a framework
for Disaggregated Media that include both improvements on existing mechanisms (e.g. 3pcc) and the develop of one or more new mechanisms like a loosely coupled mechanism that does not require the implementation of complex logic on any of the terminals.

Specifically, the proposed working group will develop the following
deliverables: 1. A framework document describing key design considerations for Disaggregated mediamechanism.
2. A specification for a loosely couple mechanism.
3. One or more specifications to improve existing mechanism to coordinate
  disaggregated media.

---

From: "Salvatore Loreto" <[email-masked]>
Date: Fri, 25 Sep 2009 12:32:11 +0200

Hi Francois,

thanks for the support to the work.

the idea for the eventual wg is to focus on both the "loosely coupled" aspects and the improvements for a centralized approach
using 3PCC or other protocols.

/Sal

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Fri 9/25/2009 12:26 AM
To: Salvatore Loreto
Cc: IETF Dispatch; Gonzalo Camarillo
Subject: RE: [dispatch] Charter Proposal for Disaggregated Media

-Francois

cheers
Sal

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 25 Sep 2009 12:49:57 +0200

Hi Salvatore,

I definitely support this proposal, and can see many use cases for it.
Be it just guidelines on the existing solutions, or new mechanisms to
support the required scenarios, we need something to address
disaggregated media, and my feeling is that the charter already looks
quite fine. Talking about it in Hiroshima will probably help refining
it.

L.

On Mon, 21 Sep 2009 13:51:51 +0300

-- 
Lorenzo Miniero <[email-masked]>

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 28 Sep 2009 16:22:55 -0400

The general approach of the charter looks good to me, but there seem
to be too many words used to describe the existing methods (which may
or may not be solutions to the problem), and a lack of sharpness in
describing the area we are focusing on.  Let me propose some
alternative text.  I think that this does not change the intention of
any of the text.

    OK

    OK

    There are a number of protocols now used that are used to
    coordinate a number of devices (e.g., Mbus, Megaco, SIP 3pcc), but
    the common methods of using those protocols all require a
    "master" device that must remain involved in the user's session
    for its entire duration.

    The objective of the proposed working group is to develop a
    framework for Disaggregated Media in "loosely-coupled" scenarios,
    where no single device can remain in the session for its entire
    duration and/or no single device has the necessary functionality
    to coordinate all of the media streams.

    The framework may include improvements on existing mechanisms
    (e.g. 3pcc), the development of one or more new mechanisms, and/or
    new methods of utilizing mechanisms.

    Specifically, the proposed working group will develop the following
    deliverables: 
    1. Use cases and functional requirements for the mechanism(s)
    2. A framework document describing key design considerations for
       disaggregated media mechanism(s)
    3. One or more specifications for new mechanism(s), to improve
       existing mechanism(s), and/or improve their utilization(s) to
       coordinate disaggregated media

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 30 Sep 2009 17:02:06 -0400

>     to coordinate all of the media streams.

We could add "and/or the session is discontinuous in time" to that list
-- that was a case discussed in the past, although we may have decided
to exclude that from consideration.

Dale