Re: [maitai] Roles of Sender and Receiver

"Elwell, John" <john.elwell@siemens-enterprise.com> Fri, 03 December 2010 08:05 UTC

Return-Path: <john.elwell@siemens-enterprise.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 9730728C19B for <maitai@core3.amsl.com>; Fri, 3 Dec 2010 00:05:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.49
X-Spam-Level:
X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 TYAaDKu1HJ1X for <maitai@core3.amsl.com>; Fri, 3 Dec 2010 00:05:25 -0800 (PST)
Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3792928C191 for <maitai@ietf.org>; Fri, 3 Dec 2010 00:05:24 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2543389; Fri, 3 Dec 2010 09:06:39 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id CB8F023F0278; Fri, 3 Dec 2010 09:06:39 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 3 Dec 2010 09:06:39 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Duckworth, Mark" <Mark.Duckworth@polycom.com>, "maitai@ietf.org" <maitai@ietf.org>
Date: Fri, 03 Dec 2010 09:06:38 +0100
Thread-Topic: [maitai] Roles of Sender and Receiver
Thread-Index: AcuSW+dX+kTRUC7+SaGEZfxuqvE6swACyAoAABZrYIA=
Message-ID: <A444A0F8084434499206E78C106220CA03C56ACE00@MCHP058A.global-ad.net>
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> <C4064AF1C9EC1F40868C033DB94958C7034749BA@XMB-RCD-111.cisco.com> <CC6CA193-F24F-4D32-BDEE-45125C2934BA@magorcorp.com> <44C6B6B2D0CF424AA90B6055548D7A61A76B37EA@CRPMBOXPRD01.polycom.com>
In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61A76B37EA@CRPMBOXPRD01.polycom.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 08:05:26 -0000

 

> -----Original Message-----
> From: maitai-bounces@ietf.org 
> [mailto:maitai-bounces@ietf.org] On Behalf Of Duckworth, Mark
> Sent: 02 December 2010 21:37
> To: maitai@ietf.org
> Subject: Re: [maitai] Roles of Sender and Receiver
> 
> > -----Original Message-----
> > From: maitai-bounces@ietf.org [mailto:maitai-bounces@ietf.org] On
> > Behalf Of Peter Musgrave
> > Sent: Thursday, December 02, 2010 3:02 PM
> > To: Mike Hammer (hmmr)
> > Cc: maitai@ietf.org
> > Subject: Re: [maitai] Roles of Sender and Receiver
> > 
> > I think this is actually a different, very interesting issue. This
> > speaks to control DURING the call and the need for that to 
> be dynamic.
> > I completely agree - but as understand the charter it's out of
> > scope...although I think it is inevitable that we will need 
> to look at
> > what exists (BFCP, conference event etc.) and determine if it can be
> > used or start to define something new.
> 
> I agree, except I think this issue is within the scope of the charter.
> The charter version 8 does say far end camera control is out of scope,
> but it also says this is in scope: "As part of the receiver 
> telling the
> sender what it wants dynamically, explicit receiver 
> notification to the
> sender of the desired video stream and video pause will be 
> considered."
> This seems to leave a lot of room for dynamic handling of video stream
> selection, within scope of the charter.
[JRE] I see "far end camera control" as referring to the ability to control the angle and zoom of a particular camera - that would be out of scope. But controlling which of several cameras to receive during the course of a call should indeed be within the charter.

John


> 
> > This might be subverted by sending all and letting the receiver take
> > them on and off hold quickly...clunky but avoid protocol work.
> > 
> > My specific question relates to the initial setup where I have two 3
> > display, 3 camera systems from different vendors. Who decides which
> > stream goes where? Sender or receiver?
> 
> I was thinking the sender would somehow indicate the spatial 
> relationship
> between the streams it sends.  Then a receiver can render it 
> appropriately
> on its display(s).
> 
> Mark
> 
> 
> > Peter
> > 
> > On 2010-12-02, at 2:47 PM, Mike Hammer (hmmr) wrote:
> > 
> > > Ummmm....
> > >
> > > Part of the issue is that with multiple participants with multiple
> > > inputs and outputs, you can't send all inputs from all 
> sites to all
> > > other sites.  You kill the network, so some judicious 
> control of what
> > is
> > > sent when and to whom is needed.  That means that some inputs
> > > (microphone or camera) are not transmitted at times.
> > >
> > > So, do we allow legs to be asymmetric or not?
> > >
> > > Interested in your view of the collective impact of these types of
> > > control decisions.
> > >
> > > Mike
> > >
> > >
> > > -----Original Message-----
> > > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
> > > Sent: Thursday, December 02, 2010 2:00 PM
> > > To: Charles Eckel (eckelcu)
> > > Cc: Mike Hammer (hmmr); maitai@ietf.org
> > > Subject: Re: [maitai] Roles of Sender and Receiver
> > >
> > >
> > > 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?
> > >
> > > 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
>