Subject: Re: [dispatch] Charter Proposal for Disaggregated Media

From: Paul Kyzivat <[email-masked]>
Date: Sat, 03 Oct 2009 18:03:01 -0400

Sal,

Sorry I've been rather unresponsive lately. I've been busy with other 
things.

I think we are starting to get somewhere with your responses below.
Also, all the other discussion on this topic is starting to gell into 
something that makes sense.

Its still my opinion that if I am calling you, and I want to use 
multiple devices for my end of the call, that should be *my* problem, 
not yours. There are many possible mechanics for achieving that.

IIUC, your argument is that making it *your* responsibility instead of 
mine allows for a more "loosely coupled" solution. I'm not entirely 
convinced of that. At the very least I am now "tightly coupled" in the 
sense that I can only make a disaggregated media call when the callee 
supports it. Unless that support becomes ubiquitous, it is a problem.

The most compelling case so far that I have seen mentioned is the 
SIP+XMPP case. Its compelling because XMPP uses session establishment 
that is incompatible with SIP. But it still suffers all the same problems.

In any case, I think the problem statement for the new WG is shaping up 
well, and there is a good community of interested parties with a variety 
of viewpoints. So I think we are now going in a good direction.

	Thanks,
	Paul

Salvatore Loreto wrote:
> Hi Paul,
> 
> thanks for the comments, please see my answers in line
> 
> cheers
> Sal
> 
> 
> Paul Kyzivat wrote:
>> 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 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?
>>
> 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.
>>> 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.
>>
>> I would argue that it is premature to assert that new mechanisms are 
>> required.
> right, that is something the community has to decide.
>>> 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.
>>
>> 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: Salvatore Loreto <[email-masked]>
Date: Tue, 06 Oct 2009 20:03:55 +0300

Hi Dale,

thanks for the support and the alternative text suggested.
I completely agree on the fact that the text describing the existing 
methods is to verbose and it needs to be shrunk,
and I like the text you propose, as well as the text to sharp the area 
we are focusing on.
I am think to reuse part of them for the new version or the charter

thanks
Sal

Dale Worley wrote:
> 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.
>
>
>
> 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.
>
>     OK
>
> 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.
>
>     OK
>
> 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.
>
>     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.
>
> like a loosely coupled mechanism that does not require the implementation 
> of complex logic on any of the terminals.
>
>     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.
>
> deliverables: 
> 1. A framework document describing key design considerations for Disaggregated 
>    mediamechanism.
> 3. One or more specifications to improve existing mechanism to coordinate
>    disaggregated media.
>
>     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
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 06 Oct 2009 20:19:18 +0300

Dale Worley wrote:
> On Mon, 2009-09-28 at 16:22 -0400, Dale Worley wrote:
>   
> 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.
>   
Hi Dale,

I have to say that the Disaggregated Media in "loosely-coupled" scenario 
is different from a scenario
where you want to correlate a new session to one discontinued in the past.

I am in principle not against the inclusion of this topic,
but I remember that there has been, one year ago or more, some 
discussion related to this issue
and several people in the wg at time suggested to not take in consideration.

However I would like to hear also the opinion of other people in the wg 
on this particular use case.

cheers
Sal

---

From: Christian Groves <[email-masked]>
Date: Wed, 07 Oct 2009 15:42:43 +1100

Hello Salvatore,

Regarding your reference to Megaco [RFC3525] in the charter I believe a 
better reference would be to ITU-T H.248.1. RFC5125 obsoletes RFC3525. 
RFC5125 points to H.248.1 and the associated H.248.x subseries as being 
the up to date documents.

Regards Christian

Salvatore Loreto wrote:
> Hi there,
>
> below is a charter proposal for a WG on Disaggregated Media.
>
> All comments, thoughts, feedbacks are very welcome!
>
> cheers
> Sal
>
>
>
> ------------------------------- 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Oct 2009 09:10:28 -0400

>> to exclude that from consideration.

I'm having difficulty understanding what is the value of this.

	Thanks,
	Paul