Re: [maitai] Roles of Sender and Receiver

Peter Musgrave <peter.musgrave@magorcorp.com> Thu, 02 December 2010 21:22 UTC

Return-Path: <peter.musgrave@magorcorp.com>
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 3491F3A6765 for <maitai@core3.amsl.com>; Thu, 2 Dec 2010 13:22:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.916
X-Spam-Level:
X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 F3jYSDT31Nhm for <maitai@core3.amsl.com>; Thu, 2 Dec 2010 13:22:03 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DB6C93A6358 for <maitai@ietf.org>; Thu, 2 Dec 2010 13:22:02 -0800 (PST)
Received: by yxt33 with SMTP id 33so836020yxt.31 for <maitai@ietf.org>; Thu, 02 Dec 2010 13:23:18 -0800 (PST)
Received: by 10.91.7.12 with SMTP id k12mr1906891agi.197.1291324998617; Thu, 02 Dec 2010 13:23:18 -0800 (PST)
Received: from [192.168.1.105] ([204.237.32.134]) by mx.google.com with ESMTPS id x31sm946175ana.29.2010.12.02.13.23.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Dec 2010 13:23:17 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Peter Musgrave <peter.musgrave@magorcorp.com>
In-Reply-To: <2D777804-734A-4561-B019-A735079B7D78@americafree.tv>
Date: Thu, 02 Dec 2010 16:23:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <89AD7954-7462-4FFC-A947-EC748E9984D4@magorcorp.com>
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>
To: Marshall Eubanks <tme@americafree.tv>
X-Mailer: Apple Mail (2.1082)
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: Thu, 02 Dec 2010 21:22:05 -0000

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). 

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. 

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
>> 
>