Re: [maitai] Roles of Sender and Receiver

Marshall Eubanks <tme@americafree.tv> Fri, 03 December 2010 03:12 UTC

Return-Path: <tme@americafree.tv>
X-Original-To: maitai@core3.amsl.com
Delivered-To: maitai@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C822628C121 for <maitai@core3.amsl.com>; Thu, 2 Dec 2010 19:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=0.599, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drvmpEZokq2D for <maitai@core3.amsl.com>; Thu, 2 Dec 2010 19:12:29 -0800 (PST)
Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id BF82128C149 for <maitai@ietf.org>; Thu, 2 Dec 2010 19:12:28 -0800 (PST)
Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 28006959BDA5; Thu, 2 Dec 2010 22:13:43 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Marshall Eubanks <tme@americafree.tv>
In-Reply-To: <89AD7954-7462-4FFC-A947-EC748E9984D4@magorcorp.com>
Date: Thu, 02 Dec 2010 22:13:42 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <19394B1A-EAD8-422E-93C6-2E362F0BE03A@americafree.tv>
References: <928969B1-F60B-47B8-A526-676E86BA7061@magorcorp.com> <C4064AF1C9EC1F40868C033DB94958C703474808@XMB-RCD-111.cisco.com> <E1CBF4C7095A3D4CAAAEAD09FBB8E08C02BD7CFC@xmb-sjc-234.amer.cisco.com> <62F4714D-7819-4BBE-A588-9BE3FADBC001@magorcorp.com> <2D777804-734A-4561-B019-A735079B7D78@americafree.tv> <89AD7954-7462-4FFC-A947-EC748E9984D4@magorcorp.com>
To: Peter Musgrave <peter.musgrave@magorcorp.com>
X-Mailer: Apple Mail (2.1081)
Cc: maitai@ietf.org
Subject: Re: [maitai] Roles of Sender and Receiver
X-BeenThere: maitai@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-stream Attributes for Improving Telepresence Application Interoperability <maitai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/maitai>, <mailto:maitai-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/maitai>
List-Post: <mailto:maitai@ietf.org>
List-Help: <mailto:maitai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/maitai>, <mailto:maitai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2010 03:12:29 -0000

On Dec 2, 2010, at 4:23 PM, Peter Musgrave wrote:

> Hi Marshal, 
> 
> That's not really the question I'm asking. In general either of the ends of these examples could be an MCU or an endpoint. I am interested in basic decisions when one side has three receivers and the other has three senders. Who decides on the mapping? The EPs could be rooms or MCUs. 
> 
> It may be that we end up with the old "master-slave" pattern - so a room might agree to let an MCU control both decisions of where to display incoming video and where to send outgoing video - and in a room to room call one side is elected to be master or they decide to split the responsibilities in some well defined way (e.g. each makes their own sender decisions). 
> 

I think this is a little deeper than that. If the MCU (or whatever) is controlling this, then the source will think that the receiver is making the decisions, while the receiver will think that that the source is making the decisions, so that (to me) says that we have to accommodate both models. 


> Also, I think that as "video router" and/or peer to peer systems are deployed, we do not want to "bake in" an MCU as a required architectural element in the specification. 

Certainly not. 

Regards
Marshall


> 
> Cheers,
> 
> Peter Musgrave
> 
> On 2010-12-02, at 3:17 PM, Marshall Eubanks wrote:
> 
>> 
>> On Dec 2, 2010, at 2:00 PM, Peter Musgrave wrote:
>> 
>>> 
>>> On 2010-12-02, at 11:10 AM, Charles Eckel (eckelcu) wrote:
>>> 
>>>> have 3 cameras, left, center, and right.
>>>> I can provide these as:
>>>> - 3 separate streams
>>>> - 1 active speaker switched stream
>>>> - 1 stream composed of the three
>>> 
>>> Ok, I see what you're after. 
>>> 
>>> In the case where the receiver elects to get three separate streams, then I have a refinement for my question. 
>>> 
>>> Who now decides how the streams from A map on to screens at B?
>> 
>> The MCU, of course. So, all 3 could be sent to the MCU, and it could send a 3-tuple to some end points, switched to others, composited to
>> still others, and even combinations to some. 
>> 
>> The point is that there could be middleware that knows more about what is going on than any of the endpoints, which only have partial knowledge.
>> 
>> 
>> Regards
>> Marshall
>> 
>> 
>> 
>>> 
>>> A could send streams targeted at specific screens at B (after examining B's description of it's screens)
>>> 
>>> -or-
>>> 
>>> B could send A instructions on where to send each stream (based on examining A's description of it's cameras)
>>> 
>>> -or-
>>> 
>>> We can find use-cases in which both techniques might be required. 
>>> 
>>> I am trying to decide how complete the information in a room description really needs to be. While I like the idea of a reasonably complete physical description (since it is very future proof) - I think it imposes a burden on each side which might not be warranted. The other extreme (just label cameras left, center, right) seems to obviously limited. Where is the middle ground?
>>> 
>>> Peter Musgrave
>>> _______________________________________________
>>> maitai mailing list
>>> maitai@ietf.org
>>> https://www.ietf.org/mailman/listinfo/maitai
>>> 
>> 
> 
>