From Mark.Duckworth@polycom.com Thu Mar 1 07:08:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9145121E80F0 for ; Thu, 1 Mar 2012 07:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLO9LEmA8PJc for ; Thu, 1 Mar 2012 07:08:16 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F038821E80B8 for ; Thu, 1 Mar 2012 07:08:15 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 1 Mar 2012 07:08:15 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Thu, 1 Mar 2012 07:08:12 -0800 Thread-Topic: [clue] propose "mutually exclusive" attribute to replace simutaneous sets Thread-Index: Acz3WAC9ZpYpPZd9STmHkizU63siQwAZJJPQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C74E3@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> <4F4EE72B.1050903@nteczone.com> In-Reply-To: <4F4EE72B.1050903@nteczone.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: [clue] propose "mutually exclusive" attribute to replace simutaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:08:16 -0000 We were trying to address the concern raised on Wednesday morning at the in= terim meeting about the representation of simultaneous sets becoming unwiel= dy in some cases. From the meeting minutes Paul published: "We're concerned about Simultaneous Sets becoming combinatorial (for large = numbers of participants with multiple complex capture sets). We don't have = a use case for these types of environments yet. Do we need them?" So if the group thinks we don't really need to worry about this, and the cu= rrent simultaneous set concept in draft-ietf-clue-framework-03 is fine the = way it is, that is okay with me. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, February 29, 2012 10:04 PM > To: clue@ietf.org > Subject: Re: [clue] propose "mutually exclusive" attribute to replace > simutaneous sets >=20 > Hello Mark, >=20 > From a readability point of view I do find simultaneous sets easier to > understand. I think that from an interop point of view it may be better t= he > capturer to say "here's the combinations I support" rather than "I suppor= t > everything except these combinations". The capturer and provider may not > have the same view of "everything". >=20 > From the mutually exclusive examples there does seem to be some > duplication. The mutually exclusive pairs seem to be listed twice i.e. > VC1,{VC3} and VC3,{VC1}. Could it not be deduced from a single pair that > they can't be used at the same time? >=20 > Regards, Christian >=20 > On 1/03/2012 9:43 AM, Duckworth, Mark wrote: > > > > This is a proposal from all the framework authors. Please review. > > > > We propose removing the concept of "simultaneous sets" and replacing > > it with a new media capture attribute called "mutually exclusive". The > > purpose is to have a more concise way to indicate which media captures > > cannot be used at the same time, which we believe scales better than > > the simultaneous set idea when there are multiple mutually exclusive > > constraints. This is in response to concerns discussed at the interim > > meeting about scalability of simultaneous sets, and confusion between > > simultaneous sets and capture set entries. > > > > New Media Capture attribute: > > > > Mutually-exclusive: {list of MCs that cannot be used at same time as > > this MC} > > > > Consider the example of a room system where there are 3 cameras each > > > > of which can send a separate capture covering 2 persons each- VC0, > > > > VC1, VC2. The middle camera can also zoom out and show all 6 > > > > persons, VC3. But the middle camera cannot be used in both modes at > > > > the same time - it has to either show the space where 2 participants > > > > sit or the whole 6 seats, but not both at the same time. > > > > The provider specifies this with the following video capture attribute > > values: > > > > VC1 - mutually-exclusive=3D{VC3} > > > > VC3 - mutually-exclusive=3D{VC1} > > > > A provider must advertise mutually exclusive attributes that allow all > > the media captures in a capture set entry to be used at the same time. > > > > Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. > > > > We will update the example in section 11.1 to show the new attribute > > rather than the simultaneous sets. > > > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Thu Mar 1 07:24:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2362F21E81DE for ; Thu, 1 Mar 2012 07:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZnfHMAx+NL7 for ; Thu, 1 Mar 2012 07:24:07 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1521E81DD for ; Thu, 1 Mar 2012 07:24:06 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 1 Mar 2012 07:24:04 -0800 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Thu, 1 Mar 2012 07:24:02 -0800 Thread-Topic: [clue] author or editor? Thread-Index: Acz3vofc31RqAEA8RjSNUIudzUB75Q== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FF@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FFCRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] author or editor? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:24:09 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FFCRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, I'm sorry if I'm not using the correct term for author vs. editor. The doc= ument itself still lists four names as authors (at the end it says "authors= ' addresses"). Should I change that? I don't think I _can_ change it, it = seems to be part of the predetermined document format when using XML2RFC. = If you know how to change this so it says "editors" instead, please let me = know. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Wednesday, February 29, 2012 7:41 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simut= aneous sets Mark, Just to be precise you are the editors not the authors, this is a WG draft. Roni --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FFCRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

I’m sorry if I’m not using the correct term= for author vs. editor.  The document itself still lists four names as= authors (at the end it says “authors’ addresses”). = Should I change that?  I don’t think I _can_ change it, = it seems to be part of the predetermined document format when using XML2RFC= .  If you know how to change this so it says “editors” ins= tead, please let me know.

Mark

 

<= p class=3DMsoNormal>From: Roni Even [mailto:ron.even.tlv@gmail.com]
Se= nt: Wednesday, February 29, 2012 7:41 PM
To: Duckworth, Mark;= clue@ietf.org
Subject: RE: [clue] propose "mutually exclusi= ve" attribute to replace simutaneous sets

<= /div>

 

Mark,

Just to be precise you are the editors not the au= thors, this is a WG draft.

Roni

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FFCRPMBOXPRD01p_-- From marshall.eubanks@gmail.com Thu Mar 1 07:46:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A8221E81EF for ; Thu, 1 Mar 2012 07:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4AVedF3A07d for ; Thu, 1 Mar 2012 07:46:31 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3F21E81EC for ; Thu, 1 Mar 2012 07:46:30 -0800 (PST) Received: by bkuw5 with SMTP id w5so748008bku.31 for ; Thu, 01 Mar 2012 07:46:29 -0800 (PST) Received-SPF: pass (google.com: domain of marshall.eubanks@gmail.com designates 10.112.84.68 as permitted sender) client-ip=10.112.84.68; Authentication-Results: mr.google.com; spf=pass (google.com: domain of marshall.eubanks@gmail.com designates 10.112.84.68 as permitted sender) smtp.mail=marshall.eubanks@gmail.com; dkim=pass header.i=marshall.eubanks@gmail.com Received: from mr.google.com ([10.112.84.68]) by 10.112.84.68 with SMTP id w4mr2618438lby.37.1330616789917 (num_hops = 1); Thu, 01 Mar 2012 07:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=UiOJDDhkLWqYA0mLD6CZxcJO+4mMT/FuavgqxJReqDE=; b=qdm2OusCDmF2/4y+9PbByeiHw9UQJxnDKYU0DmsiPAWlFyzc5cp4fX+88BAWNvo/Mk 9NTzLhannzpJ9sniuTOwBW0XQuOVMANwLqscCk+aA21IULNvRtLnTFbdk5gfDGUsh7Kd Vv0zt/ROGJ70eueWV9UFZBu3Pfi/VPCdRSwDU= MIME-Version: 1.0 Received: by 10.112.84.68 with SMTP id w4mr2139166lby.37.1330616789842; Thu, 01 Mar 2012 07:46:29 -0800 (PST) Received: by 10.112.130.7 with HTTP; Thu, 1 Mar 2012 07:46:29 -0800 (PST) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FF@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FF@CRPMBOXPRD01.polycom.com> Date: Thu, 1 Mar 2012 10:46:29 -0500 Message-ID: From: Marshall Eubanks To: "Duckworth, Mark" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "clue@ietf.org" Subject: Re: [clue] author or editor? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:46:31 -0000 Dear Roni; On Thu, Mar 1, 2012 at 10:24 AM, Duckworth, Mark wrote: > Hi Roni, > > I=92m sorry if I=92m not using the correct term for author vs. editor. = =A0The > document itself still lists four names as authors (at the end it says > =93authors=92 addresses=94).=A0 Should I change that?=A0 I don=92t think = I _can_ change > it, it seems to be part of the predetermined document format when using > XML2RFC.=A0 If you know how to change this so it says =93editors=94 inste= ad, > please let me know. > Don't change this. See below. > Mark > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Wednesday, February 29, 2012 7:41 PM > To: Duckworth, Mark; clue@ietf.org > Subject: RE: [clue] propose "mutually exclusive" attribute to replace > simutaneous sets > > > > Mark, > > Just to be precise you are the editors not the authors, this is a WG draf= t. > I don't think you are correct. Some documents do have "editors," generally because there are too many authors and one person takes the overall pen. However, - RFC 2223 is "Instructions to RFC Authors" - RFC 5741 also talks about RFC Authors. And, for documents with N >> 1 authors and an editor, the authors are still authors and should be listed as such. (The IESG should not, IMHO, approve a document where there is an editor and a hidden host of auth= ors. Of course, for WG drafts, the WG is in control and can give the pen to someone else. Still, however, the authors of text remain the authors of text, even if they no longer are in change control. So, I think Mark should keep it as authors. Regards Marshall > Roni > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From stewe@stewe.org Thu Mar 1 09:01:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839D221F8868 for ; Thu, 1 Mar 2012 09:01:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsXC3IPWnNG5 for ; Thu, 1 Mar 2012 09:01:18 -0800 (PST) Received: from AM1EHSOBE006.bigfish.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id E717021F885C for ; Thu, 1 Mar 2012 09:01:17 -0800 (PST) Received: from mail29-am1-R.bigfish.com (10.3.201.242) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Mar 2012 17:01:16 +0000 Received: from mail29-am1 (localhost [127.0.0.1]) by mail29-am1-R.bigfish.com (Postfix) with ESMTP id 8944F180558; Thu, 1 Mar 2012 17:01:16 +0000 (UTC) X-SpamScore: -34 X-BigFish: PS-34(zzbb2dI9371I542M1432N98dK4015Izz1202h1082kzz1033IL8275bh8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT002.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail29-am1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT002.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail29-am1 (localhost.localdomain [127.0.0.1]) by mail29-am1 (MessageSwitch) id 1330621274247027_9609; Thu, 1 Mar 2012 17:01:14 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.247]) by mail29-am1.bigfish.com (Postfix) with ESMTP id 35BE42C004B; Thu, 1 Mar 2012 17:01:14 +0000 (UTC) Received: from BL2PRD0710HT002.namprd07.prod.outlook.com (157.56.240.133) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Mar 2012 17:01:13 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.107]) by BL2PRD0710HT002.namprd07.prod.outlook.com ([10.255.102.37]) with mapi id 14.16.0123.000; Thu, 1 Mar 2012 17:01:12 +0000 From: Stephan Wenger To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Language re capture axis Thread-Index: AQHM6/tnLytIKH/OzUOAFdCyR7eqWJZUDShAgAAQEoCAAAUfgIAACqsAgACmZwCAAGhMAA== Date: Thu, 1 Mar 2012 17:01:12 +0000 Message-ID: In-Reply-To: <4F4EE356.9030501@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [clue] Language re capture axis X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:01:19 -0000 Hi Christian, No, it wouldn't (without the note, or a flag, or explicit information about he axis of capture). As I have shown on the whiteboard in Andover, the axis of capture of a camera can be independent from the area of capture, if there is a digital pan/zoom option build into the camera (as it is in most cameras nowadays). =20 I can live with all three options: 1) note only as originally proposed by me with modifications by Mark (which basically disallows camera arrangements where the axis of capture if very different from the field of capture without sender-side geometric corrections, such as TeleSuite's old 130 degree lens with four fields of capture) 2) A flag indicating that the axis of capture is not derivable from the field of capture (as proposed by Roni), or 3) Independently defining area of capture and axis of capture. Option 3 obviously would provide the most flexibility. Is anyone here worried about wide angle lenses and a single high-res sensor, whose output is split up into multiple fields? If so, we may want to go with option 3. Stephan =20 On 2.29.2012 18:47 , "Christian Groves" wrote: >Hello Roni, > >I'm not sure I follow. Why would the provider add a flag to say whether >the axis of capture can be calculated? Wouldn't the consumer know this >from the information delivered to it? > >Regards, Christian > >On 1/03/2012 3:52 AM, Roni Even wrote: >> Hi, >> My view is that we should either point out that the axis of capture is >>not >> specified or add a value for it. My preference is that since in most >>cases >> the area of capture and point of capture will provide the axis of >>capture we >> can add a flag that will say whether the axis of capture can be >>calculated >> based on the information or not. >> Roni >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Duckworth, Mark >>> Sent: Wednesday, February 29, 2012 6:14 PM >>> To: Paul Kyzivat; clue@ietf.org >>> Subject: Re: [clue] Language re capture axis >>> >>> Paul and Stephan, >>> >>> Personally, I'd rather just leave it out altogether because I think it >>> doesn't add anything that needs to be standardized. But Stephan >>> thought it was important, so I was trying to find a way to say it in an >>> "accurate enough" way. >>> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Wednesday, February 29, 2012 10:56 AM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Language re capture axis >>>> >>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: >>>>> Hi Stephan, >>>>> >>>>> I agree in principle with your suggestion, but I think your >>>>> suggested text is not mathematically accurate. I think the axis of >>>>> capture doesn't go to the center of the area of capture. For >>>>> example, if the camera is pointed at the area of capture at an >>>>> angle, the center point of the area would not line up with the >>>>> center point of the camera's field of view (which defines the >>> axis). >>>>> So rather than try to get into the mathematical details, how about >>> this: >>>>> "Note that, for the purpose of receiver-side geometric correction, >>>>> it can be assumed that the axis of capture of directional capture >>>>> devices (cameras, directional microphones etc.) can be calculated >>>>> from the coordinates of the point of capture and area of capture." >>>> IMO this is dangerously vague. Presumably there is a real axis of >>> capture. >>>> Hopefully there is a well defined algorithm for deriving the axis >>> from >>>> the available data, so that the recipient will determine the actual >>>> axis. If so, then it should be specified or referenced from some >>>> source. Otherwise we run the risk that not all will correctly derive >>> the axis. >>>> Thanks, >>>> Paul >>>> >>>>> Mark >>>>> >>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >>>>> Behalf Of *Stephan Wenger >>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM >>>>> *To:* clue@ietf.org >>>>> *Subject:* [clue] Language re capture axis >>>>> >>>>> Hi, >>>>> >>>>> The issue I mentioned in the meeting is that nowhere in the >>>>> framework (as far as I recall) the axis of capture of a video >>>>> capture (or directional audio capture-anything that is not >>>>> omnidirectional) is undefined. Without that axis being defined, >>>>> receiver-side geometric correction is not possible. >>>>> >>>>> The issue could be solved in two ways: include attributes, per >>>>> capture, indicating angle of capture in 3D space (relative to >>>>> what???), or by making the bold assumption that the coordinates >>>>> defining area of capture plus capture point define the axis of >>>>> capture. I suggest the latter as it is easy to implement and (I >>>>> believe) >>>> practical. >>>>> The language could be something like: >>>>> >>>>> " >>>>> >>>>> Note that, for the purpose of receiver-side geometric correction, >>> it >>>>> can be assumed that the axis of capture of directional capture >>>>> devices (cameras, directional microphones etc.) is the line from >>> the >>>>> capture point to the center of the plane of capture. >>>>> >>>>> " >>>>> >>>>> Stephan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Mar 1 09:25:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A329421E8041 for ; Thu, 1 Mar 2012 09:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpBPDALnvNGN for ; Thu, 1 Mar 2012 09:25:29 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9943021E8061 for ; Thu, 1 Mar 2012 09:25:27 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id gHCP1i0041YDfWL54HRT57; Thu, 01 Mar 2012 17:25:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id gHRT1i01H07duvL3gHRTYZ; Thu, 01 Mar 2012 17:25:27 +0000 Message-ID: <4F4FB106.9070706@alum.mit.edu> Date: Thu, 01 Mar 2012 12:25:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com> <4F4EE72B.1050903@nteczone.com> In-Reply-To: <4F4EE72B.1050903@nteczone.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] propose "mutually exclusive" attribute to replace simutaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 17:25:30 -0000 This discussion is an example of why its helpful to separate a conceptual discussion of the required information from the discussion of how that information will be encoded for exchange. If the conceptual data seems bloated and redundant then we can explore optimization techniques for transmitting it. Thanks, Paul On 2/29/12 10:04 PM, Christian Groves wrote: > Hello Mark, > > From a readability point of view I do find simultaneous sets easier to > understand. I think that from an interop point of view it may be better > the capturer to say "here's the combinations I support" rather than "I > support everything except these combinations". The capturer and provider > may not have the same view of "everything". > > From the mutually exclusive examples there does seem to be some > duplication. The mutually exclusive pairs seem to be listed twice i.e. > VC1,{VC3} and VC3,{VC1}. Could it not be deduced from a single pair that > they can't be used at the same time? > > Regards, Christian > > On 1/03/2012 9:43 AM, Duckworth, Mark wrote: >> >> This is a proposal from all the framework authors. Please review. >> >> We propose removing the concept of “simultaneous sets” and replacing >> it with a new media capture attribute called “mutually exclusive”. The >> purpose is to have a more concise way to indicate which media captures >> cannot be used at the same time, which we believe scales better than >> the simultaneous set idea when there are multiple mutually exclusive >> constraints. This is in response to concerns discussed at the interim >> meeting about scalability of simultaneous sets, and confusion between >> simultaneous sets and capture set entries. >> >> New Media Capture attribute: >> >> Mutually-exclusive: {list of MCs that cannot be used at same time as >> this MC} >> >> Consider the example of a room system where there are 3 cameras each >> >> of which can send a separate capture covering 2 persons each- VC0, >> >> VC1, VC2. The middle camera can also zoom out and show all 6 >> >> persons, VC3. But the middle camera cannot be used in both modes at >> >> the same time - it has to either show the space where 2 participants >> >> sit or the whole 6 seats, but not both at the same time. >> >> The provider specifies this with the following video capture attribute >> values: >> >> VC1 – mutually-exclusive={VC3} >> >> VC3 – mutually-exclusive={VC1} >> >> A provider must advertise mutually exclusive attributes that allow all >> the media captures in a capture set entry to be used at the same time. >> >> Section 6.3 “Simultaneous Transmission Set Constraints” can be removed. >> >> We will update the example in section 11.1 to show the new attribute >> rather than the simultaneous sets. >> >> Mark >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Thu Mar 1 10:30:40 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1106621F8ADC for ; Thu, 1 Mar 2012 10:30:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Sm8jRGFac8F for ; Thu, 1 Mar 2012 10:30:35 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4019721E8165 for ; Thu, 1 Mar 2012 10:30:34 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 1 Mar 2012 10:30:33 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 1 Mar 2012 10:30:31 -0800 Thread-Topic: [clue] Language re capture axis Thread-Index: AQHM6/tnLytIKH/OzUOAFdCyR7eqWJZUDShAgAAQEoCAAAUfgIAACqsAgACmZwCAAGhMAIAAj26w Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C761E@CRPMBOXPRD01.polycom.com> References: <4F4EE356.9030501@nteczone.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C761ECRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Language re capture axis X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:30:40 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C761ECRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I still don't understand why the axis of capture is important. The way I s= ee it, the four points defining area of capture (a quadrilateral) are mappe= d to the four corner points of a video capture (a rectangle, typically with= 16:9 aspect ratio). So by mapping a quadrilateral to a rectangle, is this= enough information for the consumer to figure out whatever it needs if it = wants to perform some geometric correction? Perhaps even without knowing t= he point of capture? Example (view with fixed width font) (the numbers I use are examples to show the point, not perfectly correct fo= r a real world case) Showing Area of Capture coordinates (for an area offset to the right of a c= amera that is pointed toward the area at an angle) First a front view, from camera point of view: (100,200,30) (0,200,25) . . . (0,200,-25) . (100,200,-30) Now a top view: (0,200,z) (100,200,z) . . . (0,0,0) Camera point of capture It seems to me that if the area of capture is a trapezoid as shown, then th= e consumer will know that the interesting stuff on the right side of the im= age is at a smaller scale than the interesting stuff on the left side of th= e image. It knows this because the larger scene height on the right and th= e smaller scene height on the left are mapped onto the same video height of= the video capture. So stuff on the right must be made smaller relative to= stuff on the left to form the video capture. So now if the consumer wants to correct for this, it knows it needs to expa= nd the right side of the image relative to the left side when it renders. Notice that the consumer does not need the point of capture and capture axi= s to figure this out. I think this shows that Stephan's use case for the consumer to perform geom= etric correction can be met, hopefully without the need to specify in an RF= C how geometric transformations and calculations are done. That should be = up to the consumer to do whatever it wants. Am I missing anything here? Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Stephan Wenger > Sent: Thursday, March 01, 2012 12:01 PM > To: Christian Groves; clue@ietf.org > Subject: Re: [clue] Language re capture axis > > Hi Christian, > > No, it wouldn't (without the note, or a flag, or explicit information abo= ut he > axis of capture). > > As I have shown on the whiteboard in Andover, the axis of capture of a > camera can be independent from the area of capture, if there is a digital > pan/zoom option build into the camera (as it is in most cameras nowadays)= . > > > I can live with all three options: > 1) note only as originally proposed by me with modifications by Mark (whi= ch > basically disallows camera arrangements where the axis of capture if very > different from the field of capture without sender-side geometric > corrections, such as TeleSuite's old 130 degree lens with four fields of > capture) > 2) A flag indicating that the axis of capture is not derivable from the f= ield of > capture (as proposed by Roni), or > 3) Independently defining area of capture and axis of capture. > > Option 3 obviously would provide the most flexibility. > > Is anyone here worried about wide angle lenses and a single high-res sens= or, > whose output is split up into multiple fields? If so, we may want to go = with > option 3. > > Stephan > > > > On 2.29.2012 18:47 , "Christian Groves" > > wrote: > > >Hello Roni, > > > >I'm not sure I follow. Why would the provider add a flag to say whether > >the axis of capture can be calculated? Wouldn't the consumer know this > >from the information delivered to it? > > > >Regards, Christian > > > >On 1/03/2012 3:52 AM, Roni Even wrote: > >> Hi, > >> My view is that we should either point out that the axis of capture > >>is not specified or add a value for it. My preference is that since > >>in most cases the area of capture and point of capture will provide > >>the axis of capture we can add a flag that will say whether the axis > >>of capture can be calculated based on the information or not. > >> Roni > >> > >>> -----Original Message----- > >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >>> Of Duckworth, Mark > >>> Sent: Wednesday, February 29, 2012 6:14 PM > >>> To: Paul Kyzivat; clue@ietf.org > >>> Subject: Re: [clue] Language re capture axis > >>> > >>> Paul and Stephan, > >>> > >>> Personally, I'd rather just leave it out altogether because I think > >>> it doesn't add anything that needs to be standardized. But Stephan > >>> thought it was important, so I was trying to find a way to say it in > >>> an "accurate enough" way. > >>> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, February 29, 2012 10:56 AM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] Language re capture axis > >>>> > >>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: > >>>>> Hi Stephan, > >>>>> > >>>>> I agree in principle with your suggestion, but I think your > >>>>> suggested text is not mathematically accurate. I think the axis of > >>>>> capture doesn't go to the center of the area of capture. For > >>>>> example, if the camera is pointed at the area of capture at an > >>>>> angle, the center point of the area would not line up with the > >>>>> center point of the camera's field of view (which defines the > >>> axis). > >>>>> So rather than try to get into the mathematical details, how about > >>> this: > >>>>> "Note that, for the purpose of receiver-side geometric correction, > >>>>> it can be assumed that the axis of capture of directional capture > >>>>> devices (cameras, directional microphones etc.) can be calculated > >>>>> from the coordinates of the point of capture and area of capture." > >>>> IMO this is dangerously vague. Presumably there is a real axis of > >>> capture. > >>>> Hopefully there is a well defined algorithm for deriving the axis > >>> from > >>>> the available data, so that the recipient will determine the actual > >>>> axis. If so, then it should be specified or referenced from some > >>>> source. Otherwise we run the risk that not all will correctly > >>>> derive > >>> the axis. > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Mark > >>>>> > >>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > >>>>> Behalf Of *Stephan Wenger > >>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM > >>>>> *To:* clue@ietf.org > >>>>> *Subject:* [clue] Language re capture axis > >>>>> > >>>>> Hi, > >>>>> > >>>>> The issue I mentioned in the meeting is that nowhere in the > >>>>> framework (as far as I recall) the axis of capture of a video > >>>>> capture (or directional audio capture-anything that is not > >>>>> omnidirectional) is undefined. Without that axis being defined, > >>>>> receiver-side geometric correction is not possible. > >>>>> > >>>>> The issue could be solved in two ways: include attributes, per > >>>>> capture, indicating angle of capture in 3D space (relative to > >>>>> what???), or by making the bold assumption that the coordinates > >>>>> defining area of capture plus capture point define the axis of > >>>>> capture. I suggest the latter as it is easy to implement and (I > >>>>> believe) > >>>> practical. > >>>>> The language could be something like: > >>>>> > >>>>> " > >>>>> > >>>>> Note that, for the purpose of receiver-side geometric correction, > >>> it > >>>>> can be assumed that the axis of capture of directional capture > >>>>> devices (cameras, directional microphones etc.) is the line from > >>> the > >>>>> capture point to the center of the plane of capture. > >>>>> > >>>>> " > >>>>> > >>>>> Stephan > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C761ECRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I still don't understand wh= y the axis of capture is important.  The way I see it, the four points= defining area of capture (a quadrilateral) are mapped to the four corner p= oints of a video capture (a rectangle, typically with 16:9 aspect ratio).&n= bsp; So by mapping a quadrilateral to a rectangle, is this enough informati= on for the consumer to figure out whatever it needs if it wants to perform = some geometric correction?  Perhaps even without knowing the point of = capture?

 

= Example (view with fixed width font)

&nbs= p;

(the numbers I use are examples to show the poin= t, not perfectly correct for a real world case)

Showing Area of Capture coordinates (= for an area offset to the right of a camera that is pointed toward the area= at an angle)

 

First a front view, from camera point of view:

           &nbs= p;            &= nbsp;           &nbs= p;  (100,200,30)

    =       (0,200,25)     &nbs= p;            &= nbsp;     .

  &n= bsp;           .

 

 <= /span>

 

   &nb= sp;          .

          (0,200= ,-25)           &nbs= p;           .=

         &n= bsp;            = ;            &n= bsp;    (100,200,-30)

&nbs= p;

Now a top view:

&nb= sp;         (0,200,z)  &n= bsp;            = ;     (100,200,z)

 &= nbsp;           &nbs= p;.            =             &nb= sp;    .

 

 

 <= /p>

 

 

 

 

 

 

 

=  

 

 

       =       .

  &= nbsp;       (0,0,0)

          Camera point of = capture

 

= It seems to me that if the area of capture is a trapezoid as shown, then th= e consumer will know that the interesting stuff on the right side of the im= age is at a smaller scale than the interesting stuff on the left side of th= e image.  It knows this because the larger scene height on the right a= nd the smaller scene height on the left are mapped onto the same video heig= ht of the video capture.  So stuff on the right must be made smaller r= elative to stuff on the left to form the video capture.

 

So now if the consumer want= s to correct for this, it knows it needs to expand the right side of the im= age relative to the left side when it renders.

 

Notice that the consumer does not need= the point of capture and capture axis to figure this out.

 

I think this shows that St= ephan’s use case for the consumer to perform geometric correction can= be met, hopefully without the need to specify in an RFC how geometric tran= sformations and calculations are done.  That should be up to the consu= mer to do whatever it wants.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

Am I missing anything here?

 

Mark

 

> -----Original Message-----<= /span>

> From: clue-bounces@ietf.org [mailto:clue-bounces@iet= f.org] On Behalf Of

> Stephan Wenger

> Sent: Thursday, March 01, 2012 12:01 PM

> To: Christian Groves; clue@ietf.org

> Subject: Re: [clue] Language re capture axis

>

> Hi Christian,<= o:p>

>

> No, it= wouldn't (without the note, or a flag, or explicit information about he

> axis of capture).

>

> As I have shown on the whiteboa= rd in Andover, the axis of capture of a

> c= amera can be independent from the area of capture, if there is a digital

> pan/zoom option build into the camera (as i= t is in most cameras nowadays).

>

>

> I can live wit= h all three options:

> 1) note only as orig= inally proposed by me with modifications by Mark (which

> basically disallows camera arrangements where the axis of ca= pture if very

> different from the field of= capture without sender-side geometric

> co= rrections, such as TeleSuite's old 130 degree lens with four fields of=

> capture)

> 2)= A flag indicating that the axis of capture is not derivable from the field= of

> capture (as proposed by Roni), or

> 3) Independently defining area of capture an= d axis of capture.

>

=

> Option 3 obviously would provide the most flexibility.

>

> Is anyone her= e worried about wide angle lenses and a single high-res sensor,<= /span>

> whose output is split up into multiple fields? = If so, we may want to go with

> option 3.<= o:p>

>

> Stepha= n

>

>

>

> On 2.29.2= 012 18:47 , "Christian Groves" <Christian.Groves@nteczone.com><= /p>

> wrote:

> =

> >Hello Roni,

> >

> >I'm not sure I follow. Why would the pro= vider add a flag to say whether

> >the a= xis of capture can be calculated? Wouldn't the consumer know this

> >from the information delivered to it?

> >

> >Regard= s, Christian

> >

> >On 1/03/2012 3:52 AM, Roni Even wrote:

=

> >> Hi,

> >> My vie= w is that we should either point out that the axis of capture

> >>is not  specified or add a value for it. = My preference is that since

> >>in mo= st cases  the area of capture and point of capture will provide

> >>the axis of capture we  can add a = flag that will say whether the axis

> >&= gt;of capture can be calculated  based on the information or not.=

> >> Roni

= > >>

> >>> -----Original = Message-----

> >>> From: clue-boun= ces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf

=

> >>> Of Duckworth, Mark

= > >>> Sent: Wednesday, February 29, 2012 6:14 PM

> >>> To: Paul Kyzivat; clue@ietf.org=

> >>> Subject: Re: [clue] Language re captur= e axis

> >>>

=

> >>> Paul and Stephan,

= > >>>

> >>> Personall= y, I'd rather just leave it out altogether because I think

> >>> it doesn't add anything that needs to be sta= ndardized.  But Stephan

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>> >>>= thought it was important, so I was trying to find a way to say it in<= /o:p>

> >>> an "accurate enough" wa= y.

> >>>

> >>> Mark

> >>>

> >>>> -----Original Message----= -

> >>>> From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On

> &= gt;>>> Behalf Of Paul Kyzivat

> &g= t;>>> Sent: Wednesday, February 29, 2012 10:56 AM

> >>>> To: clue@ietf.org

<= p class=3DMsoPlainText>> >>>> Subject: Re: [clue] Language re capture axis

> >>>>

> >>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote:<= /o:p>

> >>>>> Hi Stephan,

> >>>>>

>= >>>>> I agree in principle with your suggestion, but I thin= k your

> >>>>> suggested tex= t is not mathematically accurate. I think the axis of

=

> >>>>> capture doesn't go to the center of the a= rea of capture. For

> >>>>> = example, if the camera is pointed at the area of capture at an

> >>>>> angle, the center point of the a= rea would not line up with the

> >>&g= t;>> center point of the camera's field of view (which defines the

> >>> axis).

> >>>>> So rather than try to get into the mathemat= ical details, how about

> >>> this= :

> >>>>> "Note that, f= or the purpose of receiver-side geometric correction,

=

> >>>>> it can be assumed that the axis of captur= e of directional capture

> >>>>= > devices (cameras, directional microphones etc.) can be calculated=

> >>>>> from the coordinates of = the point of capture and area of capture."

> >>> capture.=

> >>>> Hopefully there is a well de= fined algorithm for deriving the axis

> >= ;>> from

> >>>> the avail= able data, so that the recipient will determine the actual

> >>>> axis. If so, then it should be specified= or referenced from some

> >>>>= source. Otherwise we run the risk that not all will correctly

> >>>> derive

= > >>> the axis.

> >>>&= gt;      Thanks,

> >= >>>      Paul

>= ; >>>>

> >>>>> M= ark

> >>>>>

> >>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On

> >>>>> Behalf Of *St= ephan Wenger

> >>>>> *Sent:*= Wednesday, February 15, 2012 11:04 AM

> &g= t;>>>> *To:* clue@ietf.org=

> >>>>> *Subject:* [clue] L= anguage re capture axis

> >>>>&= gt;

> >>>>> Hi,

> >>>>>

>= ; >>>>> The issue I mentioned in the meeting is that nowhere= in the

> >>>>> framework (a= s far as I recall) the axis of capture of a video

> >>>>> capture (or directional audio capture-anythin= g that is not

> >>>>> omnidi= rectional) is undefined. Without that axis being defined,=

> >>>>> receiver-side geometric correction is= not possible.

> >>>>><= /o:p>

> >>>>> The issue could be solved= in two ways: include attributes, per

> >= ;>>>> capture, indicating angle of capture in 3D space (relativ= e to

> >>>>> what???), or by= making the bold assumption that the coordinates

> >>>>> c= apture. I suggest the latter as it is easy to implement and (I

> >>>>> believe)

> >>>> practical.

> &g= t;>>>> The language could be something like:<= /p>

> >>>>>

> >= >>>> "

> >>>>&= gt;

> >>>>> Note that, for t= he purpose of receiver-side geometric correction,

> >>> it

> >>>>= > can be assumed that the axis of capture of directional capture

> >>>>> devices (cameras, direction= al microphones etc.) is the line from

> >= ;>> the

> >>>>> captur= e point to the center of the plane of capture.

> >>>>>

> >>>&g= t;> "

> >>>>>

> >>>>> Stephan<= /p>

> >>>>>

> >= >>>>

> >>>>>

> >>>>> _____________________= __________________________

> >>>&g= t;> clue mailing list

> >>>>= > clue@ietf.org

> >>>>> https://www.ietf.org/mailman/listinfo/clue

> >>>> ____________________________________= ___________

> >>>> clue mailing= list

> >>>> clue@ietf.org

> >>= >> https://www= .ietf.org/mailman/listinfo/clue

> >&= gt;> _______________________________________________

> >>> clue mailing list

= > >>> clue@ietf.org

> >>> https://www.ietf.org/mailman/listinfo/clue

> >> _______________________________________= ________

> >> clue mailing list<= /o:p>

> >> clue= @ietf.org

> >> https://www.ietf.org/mailman/listinfo/= clue

> >>

> >_______________________________________________

> >clue mailing list

= > >clue@ietf.org

> >https://www.ietf.org/mailman/listinfo/clue

> >

>

> ________________________________= _______________

> clue mailing list

> clue@ietf.org

> https://www.ietf.org/mailman/listinfo/clue<= /span>

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C761ECRPMBOXPRD01p_-- From Even.roni@huawei.com Thu Mar 1 10:36:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E0521E8192 for ; Thu, 1 Mar 2012 10:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3swggyDCr-po for ; Thu, 1 Mar 2012 10:36:52 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3521F8A3C for ; Thu, 1 Mar 2012 10:36:45 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0700GC2YD0W1@szxga03-in.huawei.com> for clue@ietf.org; Fri, 02 Mar 2012 02:36:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0700M3HYD026@szxga03-in.huawei.com> for clue@ietf.org; Fri, 02 Mar 2012 02:36:36 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHN56477; Fri, 02 Mar 2012 02:36:35 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 02 Mar 2012 02:36:11 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Fri, 02 Mar 2012 02:36:30 +0800 Date: Thu, 01 Mar 2012 18:36:28 +0000 From: Roni even In-reply-to: X-Originating-IP: [172.24.1.46] To: Marshall Eubanks , "Duckworth, Mark" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [clue] author or editor? Thread-index: Acz3vofc31RqAEA8RjSNUIudzUB75f//gcOAgAC1Gso= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C74FF@CRPMBOXPRD01.polycom.com> Cc: "clue@ietf.org" Subject: Re: [clue] author or editor? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:36:53 -0000 Hi, Just to clarify, what I meant is that the moment the draft becomes a WG dra= ft changes are not by the authors but by the WG so practically they become = editors. Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Marshall E= ubanks [marshall.eubanks@gmail.com] Sent: Thursday, March 01, 2012 17:46 To: Duckworth, Mark Cc: clue@ietf.org Subject: Re: [clue] author or editor? Dear Roni; On Thu, Mar 1, 2012 at 10:24 AM, Duckworth, Mark wrote: > Hi Roni, > > I=92m sorry if I=92m not using the correct term for author vs. editor. T= he > document itself still lists four names as authors (at the end it says > =93authors=92 addresses=94). Should I change that? I don=92t think I _c= an_ change > it, it seems to be part of the predetermined document format when using > XML2RFC. If you know how to change this so it says =93editors=94 instead= , > please let me know. > Don't change this. See below. > Mark > > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Wednesday, February 29, 2012 7:41 PM > To: Duckworth, Mark; clue@ietf.org > Subject: RE: [clue] propose "mutually exclusive" attribute to replace > simutaneous sets > > > > Mark, > > Just to be precise you are the editors not the authors, this is a WG draf= t. > I don't think you are correct. Some documents do have "editors," generally because there are too many authors and one person takes the overall pen. However, - RFC 2223 is "Instructions to RFC Authors" - RFC 5741 also talks about RFC Authors. And, for documents with N >> 1 authors and an editor, the authors are still authors and should be listed as such. (The IESG should not, IMHO, approve a document where there is an editor and a hidden host of auth= ors. Of course, for WG drafts, the WG is in control and can give the pen to someone else. Still, however, the authors of text remain the authors of text, even if they no longer are in change control. So, I think Mark should keep it as authors. Regards Marshall > Roni > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From christer.holmberg@ericsson.com Thu Mar 1 12:48:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5021E8032 for ; Thu, 1 Mar 2012 12:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5uQWCHeUoer for ; Thu, 1 Mar 2012 12:48:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 02EB621E801E for ; Thu, 1 Mar 2012 12:48:36 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-1a-4f4fe0a3b6e9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DD.C8.01970.3A0EF4F4; Thu, 1 Mar 2012 21:48:36 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 1 Mar 2012 21:48:36 +0100 From: Christer Holmberg To: "Espen Berger (espeberg)" , Roni Even , Paul Kyzivat , "clue@ietf.org" Date: Thu, 1 Mar 2012 21:48:34 +0100 Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: Acz2+ZL5AGLXB0/YQaKOpV27EUsb0AABqLmwAANM3CAAITFeUA== Message-ID: <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu> <4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 20:48:38 -0000 Hi, We need to keep in mind, that *IF* we are going to associate multiple strea= ms with a single SDP m- line, and each media streams may have a different a= ttribute value, many existing values won't work, as they are per m- line. So, in this case, what if there are multiple streams associated with the m-= line, and they all have different languages? The same would apply also to other attributes, e.g. the direction attribute= s. Regards, Christer=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Esp= en Berger (espeberg) Sent: 29. helmikuuta 2012 20:43 To: Roni Even; Paul Kyzivat; clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 I agree that we should reuse the definition from RFC4796.=20 Maybe CLUE should change the name of the purpose attribute to content to fo= llow RFC4796. Avoiding confusion is important.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 29. februar 2012 17:39 To: 'Paul Kyzivat'; clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 Hi, RFC 4795 defines an attribute that can be used to specify the semantics of = the stream. The usage is left for application specific document that will p= rovide the interoperability specification. It will be good to use the defined values and the IANA registry since we ar= e also talking in CLUE about multiple streams with different content. The framework should explain how to use the values from RFC 4795 Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Wednesday, February 29, 2012 5:48 PM > To: clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 >=20 > On 2/29/12 9:53 AM, Duckworth, Mark wrote: > > Does anybody have a comment or suggestion about this idea? > > For the framework document, I'm proposing that instead of defining > our own values for the media capture purpose attribute, instead we=20 > refer to RFC4796 and use those values that are already defined. >=20 > It appears 4796 is no less vague about the semantics of the values as=20 > we have been so far. And 4796 has an IANA registry and provision to=20 > add new values via another RFC, so we can add new ones if we need them. >=20 > But its not enough if we want individual implementations and/or=20 > deployments to be able to specify their own values. >=20 > Note that 4795 allows multiple instances of mediacnt-tag to be=20 > attached to a single stream. (E.g. "a=3Dcontent: main, speaker") This=20 > could help when more than one apply to the stream. So clue might need=20 > to also allow this. >=20 > Thanks, > Paul >=20 > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Duckworth, Mark > >> Sent: Monday, February 13, 2012 10:47 AM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] purpose attribute - Review of framework-03 > >> > >> Hi Roni, > >> > >> Thanks for all the comments. We'll start addressing different > topics > >> in different email threads. > >> > >> I was thinking the media capture purpose attribute really should > mean > >> the same thing as the SDP content attribute in RFC4796. Can CLUE=20 > >> just refer to > >> RFC4796 for the definition of the purpose attribute values? =20 > >> RFC4796 already has an extension mechanism, so we can add new=20 > >> values when > needed. > >> > >> Mark > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Roni Even > >> Sent: Wednesday, February 08, 2012 8:49 AM > >> To: clue@ietf.org > >> Subject: [clue] Review of draft-ietf-clue-framework-03 > >> > >> 6. In section 6.1.1 I suggest adding one more purpose "SL" for=20 > >> sign language indicating that this is the sign language=20 > >> representation of the audio stream, see RFC4796. > >> > >> Thanks > >> Roni Even > >> > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Thu Mar 1 13:15:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA93721E8085 for ; Thu, 1 Mar 2012 13:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.173 X-Spam-Level: X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqqp2Xindj3H for ; Thu, 1 Mar 2012 13:15:06 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDBC21E803E for ; Thu, 1 Mar 2012 13:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=5507; q=dns/txt; s=iport; t=1330636505; x=1331846105; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=9uzQPH4SIG73L68Pbo/Pdfrs8KFICyEfcbe66gjxcRM=; b=ea0vEd8GZZdCMDXnYuFUfqTBTnz4Ze/A6Bjzl2u+fZwDU5Q52Trx5PP/ tNCp28leg8z5i+hQQgPMc/68EYnO0pjMMurDl8fieSUmIgZkR93WOW3/h 3kR+U49tTEgn1aL9LoWqxkxvVZ3x+SPojmqz35S2kuF/+Uql7TQ4Naj8A A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJHlT0+Q/khM/2dsb2JhbABDDrN4gQeBfQEBAQQBAQEPAR0KNBcEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodkC5oSAZ5eBIx+DAgECwEBDgJBFIVOARgGARgBgk1jBKd2OIFb X-IronPort-AV: E=Sophos;i="4.73,513,1325462400"; d="scan'208";a="67491999" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 01 Mar 2012 21:15:04 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q21LF49U000854; Thu, 1 Mar 2012 21:15:04 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 22:15:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 22:15:02 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EFC3533@XMB-AMS-214.cisco.com> In-Reply-To: <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: Acz2+ZL5AGLXB0/YQaKOpV27EUsb0AABqLmwAANM3CAAITFeUAAXAOnQ References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com><44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu><4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> From: "Espen Berger (espeberg)" To: "Christer Holmberg" , "Roni Even" , "Paul Kyzivat" , X-OriginalArrivalTime: 01 Mar 2012 21:15:03.0979 (UTC) FILETIME=[5EB147B0:01CCF7F0] Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 21:15:07 -0000 Agree, we need the flexibility to specify purpose (or content) attributes per stream. On useful use case would be to announce three captures with three different content values, e.g. "speaker", "sl", "alt" (from rfc4796), all multiplexed on the same RTP session.=20 -Espen=20 =20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 1. mars 2012 21:49 To: Espen Berger (espeberg); Roni Even; Paul Kyzivat; clue@ietf.org Subject: RE: [clue] purpose attribute - Review of framework-03 Hi, We need to keep in mind, that *IF* we are going to associate multiple streams with a single SDP m- line, and each media streams may have a different attribute value, many existing values won't work, as they are per m- line. So, in this case, what if there are multiple streams associated with the m- line, and they all have different languages? The same would apply also to other attributes, e.g. the direction attributes. Regards, Christer=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Espen Berger (espeberg) Sent: 29. helmikuuta 2012 20:43 To: Roni Even; Paul Kyzivat; clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 I agree that we should reuse the definition from RFC4796.=20 Maybe CLUE should change the name of the purpose attribute to content to follow RFC4796. Avoiding confusion is important.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 29. februar 2012 17:39 To: 'Paul Kyzivat'; clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 Hi, RFC 4795 defines an attribute that can be used to specify the semantics of the stream. The usage is left for application specific document that will provide the interoperability specification. It will be good to use the defined values and the IANA registry since we are also talking in CLUE about multiple streams with different content. The framework should explain how to use the values from RFC 4795 Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Wednesday, February 29, 2012 5:48 PM > To: clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 >=20 > On 2/29/12 9:53 AM, Duckworth, Mark wrote: > > Does anybody have a comment or suggestion about this idea? > > For the framework document, I'm proposing that instead of defining > our own values for the media capture purpose attribute, instead we=20 > refer to RFC4796 and use those values that are already defined. >=20 > It appears 4796 is no less vague about the semantics of the values as=20 > we have been so far. And 4796 has an IANA registry and provision to=20 > add new values via another RFC, so we can add new ones if we need them. >=20 > But its not enough if we want individual implementations and/or=20 > deployments to be able to specify their own values. >=20 > Note that 4795 allows multiple instances of mediacnt-tag to be=20 > attached to a single stream. (E.g. "a=3Dcontent: main, speaker") This=20 > could help when more than one apply to the stream. So clue might need=20 > to also allow this. >=20 > Thanks, > Paul >=20 > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Duckworth, Mark > >> Sent: Monday, February 13, 2012 10:47 AM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] purpose attribute - Review of framework-03 > >> > >> Hi Roni, > >> > >> Thanks for all the comments. We'll start addressing different > topics > >> in different email threads. > >> > >> I was thinking the media capture purpose attribute really should > mean > >> the same thing as the SDP content attribute in RFC4796. Can CLUE=20 > >> just refer to > >> RFC4796 for the definition of the purpose attribute values? =20 > >> RFC4796 already has an extension mechanism, so we can add new=20 > >> values when > needed. > >> > >> Mark > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > >> Behalf Of Roni Even > >> Sent: Wednesday, February 08, 2012 8:49 AM > >> To: clue@ietf.org > >> Subject: [clue] Review of draft-ietf-clue-framework-03 > >> > >> 6. In section 6.1.1 I suggest adding one more purpose "SL" for=20 > >> sign language indicating that this is the sign language=20 > >> representation of the audio stream, see RFC4796. > >> > >> Thanks > >> Roni Even > >> > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Thu Mar 1 13:21:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FB321E8219 for ; Thu, 1 Mar 2012 13:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.217 X-Spam-Level: X-Spam-Status: No, score=-10.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYtDKjrBIjFj for ; Thu, 1 Mar 2012 13:21:25 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAB121E8218 for ; Thu, 1 Mar 2012 13:21:25 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-a4-4f4fe854f0a2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2C.1B.01970.458EF4F4; Thu, 1 Mar 2012 22:21:24 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 1 Mar 2012 22:21:24 +0100 From: Christer Holmberg To: "Espen Berger (espeberg)" , Roni Even , Paul Kyzivat , "clue@ietf.org" Date: Thu, 1 Mar 2012 22:17:36 +0100 Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: Acz2+ZL5AGLXB0/YQaKOpV27EUsb0AABqLmwAANM3CAAITFeUAAXAOnQAACh51M= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F48C5F8@ESESSCMS0356.eemea.ericsson.se> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com><44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu><4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se>, <92DF9533227FC14F946C7321074B8C9EFC3533@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EFC3533@XMB-AMS-214.cisco.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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 21:21:26 -0000 Hi, > Agree, we need the flexibility to specify purpose (or content) > attributes per stream. > > On useful use case would be to announce three captures with three > different content values, e.g. "speaker", "sl", "alt" (from rfc4796), > all multiplexed on the same RTP session. In that case we cannot use existing attributes, but we would have to specif= y something new, which allows to give values e.g. per SSRC. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 1. mars 2012 21:49 To: Espen Berger (espeberg); Roni Even; Paul Kyzivat; clue@ietf.org Subject: RE: [clue] purpose attribute - Review of framework-03 Hi, We need to keep in mind, that *IF* we are going to associate multiple streams with a single SDP m- line, and each media streams may have a different attribute value, many existing values won't work, as they are per m- line. So, in this case, what if there are multiple streams associated with the m- line, and they all have different languages? The same would apply also to other attributes, e.g. the direction attributes. Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Espen Berger (espeberg) Sent: 29. helmikuuta 2012 20:43 To: Roni Even; Paul Kyzivat; clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 I agree that we should reuse the definition from RFC4796. Maybe CLUE should change the name of the purpose attribute to content to follow RFC4796. Avoiding confusion is important. -Espen -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 29. februar 2012 17:39 To: 'Paul Kyzivat'; clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 Hi, RFC 4795 defines an attribute that can be used to specify the semantics of the stream. The usage is left for application specific document that will provide the interoperability specification. It will be good to use the defined values and the IANA registry since we are also talking in CLUE about multiple streams with different content. The framework should explain how to use the values from RFC 4795 Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Wednesday, February 29, 2012 5:48 PM > To: clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > On 2/29/12 9:53 AM, Duckworth, Mark wrote: > > Does anybody have a comment or suggestion about this idea? > > For the framework document, I'm proposing that instead of defining > our own values for the media capture purpose attribute, instead we > refer to RFC4796 and use those values that are already defined. > > It appears 4796 is no less vague about the semantics of the values as > we have been so far. And 4796 has an IANA registry and provision to > add new values via another RFC, so we can add new ones if we need them. > > But its not enough if we want individual implementations and/or > deployments to be able to specify their own values. > > Note that 4795 allows multiple instances of mediacnt-tag to be > attached to a single stream. (E.g. "a=3Dcontent: main, speaker") This > could help when more than one apply to the stream. So clue might need > to also allow this. > > Thanks, > Paul > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf Of Duckworth, Mark > >> Sent: Monday, February 13, 2012 10:47 AM > >> To: Roni Even; clue@ietf.org > >> Subject: Re: [clue] purpose attribute - Review of framework-03 > >> > >> Hi Roni, > >> > >> Thanks for all the comments. We'll start addressing different > topics > >> in different email threads. > >> > >> I was thinking the media capture purpose attribute really should > mean > >> the same thing as the SDP content attribute in RFC4796. Can CLUE > >> just refer to > >> RFC4796 for the definition of the purpose attribute values? > >> RFC4796 already has an extension mechanism, so we can add new > >> values when > needed. > >> > >> Mark > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >> Behalf Of Roni Even > >> Sent: Wednesday, February 08, 2012 8:49 AM > >> To: clue@ietf.org > >> Subject: [clue] Review of draft-ietf-clue-framework-03 > >> > >> 6. In section 6.1.1 I suggest adding one more purpose "SL" for > >> sign language indicating that this is the sign language > >> representation of the audio stream, see RFC4796. > >> > >> Thanks > >> Roni Even > >> > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Mar 1 13:43:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020C221E8217 for ; Thu, 1 Mar 2012 13:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMaAqfLECAKt for ; Thu, 1 Mar 2012 13:43:29 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id AD85C21E8261 for ; Thu, 1 Mar 2012 13:43:28 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta06.westchester.pa.mail.comcast.net with comcast id gMh61i00B0bG4ec56MjQjt; Thu, 01 Mar 2012 21:43:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id gMjQ1i01F07duvL3PMjQqu; Thu, 01 Mar 2012 21:43:24 +0000 Message-ID: <4F4FED7A.6090105@alum.mit.edu> Date: Thu, 01 Mar 2012 16:43:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christer Holmberg References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu> <4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 21:43:30 -0000 Christer, I think the proposal is to adopt the names used in 4296. Then they could be used in the content attribute when that makes sense, but also be used in the clue-specific messages even if they aren't SDP. Your point about multiple streams on one m-line applies to many SDP elements. Thanks, Paul On 3/1/12 3:48 PM, Christer Holmberg wrote: > > Hi, > > We need to keep in mind, that *IF* we are going to associate multiple streams with a single SDP m- line, and each media streams may have a different attribute value, many existing values won't work, as they are per m- line. > > So, in this case, what if there are multiple streams associated with the m- line, and they all have different languages? > > The same would apply also to other attributes, e.g. the direction attributes. > > Regards, > > Christer > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Espen Berger (espeberg) > Sent: 29. helmikuuta 2012 20:43 > To: Roni Even; Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > I agree that we should reuse the definition from RFC4796. > > Maybe CLUE should change the name of the purpose attribute to content to follow RFC4796. Avoiding confusion is important. > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: 29. februar 2012 17:39 > To: 'Paul Kyzivat'; clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > Hi, > RFC 4795 defines an attribute that can be used to specify the semantics of the stream. The usage is left for application specific document that will provide the interoperability specification. > It will be good to use the defined values and the IANA registry since we are also talking in CLUE about multiple streams with different content. > The framework should explain how to use the values from RFC 4795 Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, February 29, 2012 5:48 PM >> To: clue@ietf.org >> Subject: Re: [clue] purpose attribute - Review of framework-03 >> >> On 2/29/12 9:53 AM, Duckworth, Mark wrote: >>> Does anybody have a comment or suggestion about this idea? >>> For the framework document, I'm proposing that instead of defining >> our own values for the media capture purpose attribute, instead we >> refer to RFC4796 and use those values that are already defined. >> >> It appears 4796 is no less vague about the semantics of the values as >> we have been so far. And 4796 has an IANA registry and provision to >> add new values via another RFC, so we can add new ones if we need > them. >> >> But its not enough if we want individual implementations and/or >> deployments to be able to specify their own values. >> >> Note that 4795 allows multiple instances of mediacnt-tag to be >> attached to a single stream. (E.g. "a=content: main, speaker") This >> could help when more than one apply to the stream. So clue might need >> to also allow this. >> >> Thanks, >> Paul >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Duckworth, Mark >>>> Sent: Monday, February 13, 2012 10:47 AM >>>> To: Roni Even; clue@ietf.org >>>> Subject: Re: [clue] purpose attribute - Review of framework-03 >>>> >>>> Hi Roni, >>>> >>>> Thanks for all the comments. We'll start addressing different >> topics >>>> in different email threads. >>>> >>>> I was thinking the media capture purpose attribute really should >> mean >>>> the same thing as the SDP content attribute in RFC4796. Can CLUE >>>> just refer to >>>> RFC4796 for the definition of the purpose attribute values? >>>> RFC4796 already has an extension mechanism, so we can add new >>>> values when >> needed. >>>> >>>> Mark >>>> >>>> =================================== >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Roni Even >>>> Sent: Wednesday, February 08, 2012 8:49 AM >>>> To: clue@ietf.org >>>> Subject: [clue] Review of draft-ietf-clue-framework-03 >>>> >>>> 6. In section 6.1.1 I suggest adding one more purpose "SL" for >>>> sign language indicating that this is the sign language >>>> representation of the audio stream, see RFC4796. >>>> >>>> Thanks >>>> Roni Even >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Mar 1 13:53:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D84121E81F5 for ; Thu, 1 Mar 2012 13:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr9ro7whRfMk for ; Thu, 1 Mar 2012 13:53:25 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCFE21E81D6 for ; Thu, 1 Mar 2012 13:53:18 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta09.westchester.pa.mail.comcast.net with comcast id gMs81i0081wpRvQ59MtKhQ; Thu, 01 Mar 2012 21:53:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id gMtK1i00U07duvL3eMtKUD; Thu, 01 Mar 2012 21:53:19 +0000 Message-ID: <4F4FEFCD.7000806@alum.mit.edu> Date: Thu, 01 Mar 2012 16:53:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Duckworth, Mark" References: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> <4F4E4A81.6070006@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Language re capture axis X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 21:53:26 -0000 On 2/29/12 11:14 AM, Duckworth, Mark wrote: > Paul and Stephan, > > Personally, I'd rather just leave it out altogether because I think it doesn't add anything that needs to be standardized. But Stephan thought it was important, so I was trying to find a way to say it in an "accurate enough" way. If there is no widespread interest in having this, and those who have asked about it are happy without, then I'm fine with leaving it out. If it is to be mentioned, with the idea that the recipient might use it for something, then I think it should be made clear how it can be determined. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Wednesday, February 29, 2012 10:56 AM >> To: clue@ietf.org >> Subject: Re: [clue] Language re capture axis >> >> On 2/29/12 10:10 AM, Duckworth, Mark wrote: >>> Hi Stephan, >>> >>> I agree in principle with your suggestion, but I think your suggested >>> text is not mathematically accurate. I think the axis of capture >>> doesn't go to the center of the area of capture. For example, if the >>> camera is pointed at the area of capture at an angle, the center point >>> of the area would not line up with the center point of the camera's >>> field of view (which defines the axis). >>> >>> So rather than try to get into the mathematical details, how about this: >>> >>> "Note that, for the purpose of receiver-side geometric correction, it >>> can be assumed that the axis of capture of directional capture devices >>> (cameras, directional microphones etc.) can be calculated from the >>> coordinates of the point of capture and area of capture." >> >> IMO this is dangerously vague. Presumably there is a real axis of capture. >> Hopefully there is a well defined algorithm for deriving the axis from the >> available data, so that the recipient will determine the actual axis. If so, then >> it should be specified or referenced from some source. Otherwise we run >> the risk that not all will correctly derive the axis. >> >> Thanks, >> Paul >> >>> Mark >>> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >>> Of *Stephan Wenger >>> *Sent:* Wednesday, February 15, 2012 11:04 AM >>> *To:* clue@ietf.org >>> *Subject:* [clue] Language re capture axis >>> >>> Hi, >>> >>> The issue I mentioned in the meeting is that nowhere in the framework >>> (as far as I recall) the axis of capture of a video capture (or >>> directional audio capture-anything that is not omnidirectional) is >>> undefined. Without that axis being defined, receiver-side geometric >>> correction is not possible. >>> >>> The issue could be solved in two ways: include attributes, per >>> capture, indicating angle of capture in 3D space (relative to >>> what???), or by making the bold assumption that the coordinates >>> defining area of capture plus capture point define the axis of >>> capture. I suggest the latter as it is easy to implement and (I believe) >> practical. >>> >>> The language could be something like: >>> >>> " >>> >>> Note that, for the purpose of receiver-side geometric correction, it >>> can be assumed that the axis of capture of directional capture devices >>> (cameras, directional microphones etc.) is the line from the capture >>> point to the center of the plane of capture. >>> >>> " >>> >>> Stephan >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Mar 1 14:14:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7F21E8359 for ; Thu, 1 Mar 2012 14:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2mgo5A7iqYJ for ; Thu, 1 Mar 2012 14:14:18 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id A6E7821E8363 for ; Thu, 1 Mar 2012 14:14:18 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id gMz21i00327AodY51NEJrL; Thu, 01 Mar 2012 22:14:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id gNEJ1i00k07duvL3fNEJSh; Thu, 01 Mar 2012 22:14:18 +0000 Message-ID: <4F4FF4B8.6040205@alum.mit.edu> Date: Thu, 01 Mar 2012 17:14:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com><44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu><4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> <92DF9533227FC14F946C7321074B8C9EFC3533@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EFC3533@XMB-AMS-214.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:14:19 -0000 On 3/1/12 4:15 PM, Espen Berger (espeberg) wrote: > Agree, we need the flexibility to specify purpose (or content) > attributes per stream. > > On useful use case would be to announce three captures with three > different content values, e.g. "speaker", "sl", "alt" (from rfc4796), > all multiplexed on the same RTP session. Agree with the above. But I'm a bit confused about the distinction between "speaker" and "main". In a typical 3-screen telepresence system, would the captures for those screens be "main" or "speaker"? Or maybe both, since there are likely to be speakers in each capture, and no "designated" main speaker. Or maybe the use of "speaker" should be reserved for cases where there is a designated speaker or leader, and then used to mark the capture containing that person. But then it might also still be "main" as well. Thanks, Paul > -Espen > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 1. mars 2012 21:49 > To: Espen Berger (espeberg); Roni Even; Paul Kyzivat; clue@ietf.org > Subject: RE: [clue] purpose attribute - Review of framework-03 > > > Hi, > > We need to keep in mind, that *IF* we are going to associate multiple > streams with a single SDP m- line, and each media streams may have a > different attribute value, many existing values won't work, as they are > per m- line. > > So, in this case, what if there are multiple streams associated with the > m- line, and they all have different languages? > > The same would apply also to other attributes, e.g. the direction > attributes. > > Regards, > > Christer > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Espen Berger (espeberg) > Sent: 29. helmikuuta 2012 20:43 > To: Roni Even; Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > I agree that we should reuse the definition from RFC4796. > > Maybe CLUE should change the name of the purpose attribute to content to > follow RFC4796. Avoiding confusion is important. > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: 29. februar 2012 17:39 > To: 'Paul Kyzivat'; clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > Hi, > RFC 4795 defines an attribute that can be used to specify the semantics > of the stream. The usage is left for application specific document that > will provide the interoperability specification. > It will be good to use the defined values and the IANA registry since we > are also talking in CLUE about multiple streams with different content. > The framework should explain how to use the values from RFC 4795 Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, February 29, 2012 5:48 PM >> To: clue@ietf.org >> Subject: Re: [clue] purpose attribute - Review of framework-03 >> >> On 2/29/12 9:53 AM, Duckworth, Mark wrote: >>> Does anybody have a comment or suggestion about this idea? >>> For the framework document, I'm proposing that instead of defining >> our own values for the media capture purpose attribute, instead we >> refer to RFC4796 and use those values that are already defined. >> >> It appears 4796 is no less vague about the semantics of the values as >> we have been so far. And 4796 has an IANA registry and provision to >> add new values via another RFC, so we can add new ones if we need > them. >> >> But its not enough if we want individual implementations and/or >> deployments to be able to specify their own values. >> >> Note that 4795 allows multiple instances of mediacnt-tag to be >> attached to a single stream. (E.g. "a=content: main, speaker") This >> could help when more than one apply to the stream. So clue might need >> to also allow this. >> >> Thanks, >> Paul >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Duckworth, Mark >>>> Sent: Monday, February 13, 2012 10:47 AM >>>> To: Roni Even; clue@ietf.org >>>> Subject: Re: [clue] purpose attribute - Review of framework-03 >>>> >>>> Hi Roni, >>>> >>>> Thanks for all the comments. We'll start addressing different >> topics >>>> in different email threads. >>>> >>>> I was thinking the media capture purpose attribute really should >> mean >>>> the same thing as the SDP content attribute in RFC4796. Can CLUE >>>> just refer to >>>> RFC4796 for the definition of the purpose attribute values? >>>> RFC4796 already has an extension mechanism, so we can add new >>>> values when >> needed. >>>> >>>> Mark >>>> >>>> =================================== >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Roni Even >>>> Sent: Wednesday, February 08, 2012 8:49 AM >>>> To: clue@ietf.org >>>> Subject: [clue] Review of draft-ietf-clue-framework-03 >>>> >>>> 6. In section 6.1.1 I suggest adding one more purpose "SL" for >>>> sign language indicating that this is the sign language >>>> representation of the audio stream, see RFC4796. >>>> >>>> Thanks >>>> Roni Even >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Thu Mar 1 14:31:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A3521E83A4 for ; Thu, 1 Mar 2012 14:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7seOcbX+Qn6 for ; Thu, 1 Mar 2012 14:31:54 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1B21A21E809C for ; Thu, 1 Mar 2012 14:31:53 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 1 Mar 2012 14:31:53 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , Christer Holmberg Date: Thu, 1 Mar 2012 14:33:16 -0800 Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: Acz39FrY/YBS/iugQZyZnRBWCHD4qQABmNmA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C77CC@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu> <4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> <4F4FED7A.6090105@alum.mit.edu> In-Reply-To: <4F4FED7A.6090105@alum.mit.edu> 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 Cc: "clue@ietf.org" Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:31:54 -0000 Yes, I agree with Paul, my proposal meant to use the mediacnt values from R= FC4796 as the possible values for the "purpose" media capture attribute in = CLUE. This attribute wouldn't necessarily be communicated via SDP. Somebody else suggested changing the name of the "purpose" attribute to "co= ntent", to be a closer match with RFC4796, which sounds good to me. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, March 01, 2012 4:43 PM > To: Christer Holmberg > Cc: clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 >=20 > Christer, >=20 > I think the proposal is to adopt the names used in 4296. Then they could = be > used in the content attribute when that makes sense, but also be used in = the > clue-specific messages even if they aren't SDP. >=20 > Your point about multiple streams on one m-line applies to many SDP > elements. >=20 > Thanks, > Paul >=20 > On 3/1/12 3:48 PM, Christer Holmberg wrote: > > > > Hi, > > > > We need to keep in mind, that *IF* we are going to associate multiple > streams with a single SDP m- line, and each media streams may have a > different attribute value, many existing values won't work, as they are p= er > m- line. > > > > So, in this case, what if there are multiple streams associated with th= e m- > line, and they all have different languages? > > > > The same would apply also to other attributes, e.g. the direction attri= butes. > > > > Regards, > > > > Christer > > > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Espen Berger (espeberg) > > Sent: 29. helmikuuta 2012 20:43 > > To: Roni Even; Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] purpose attribute - Review of framework-03 > > > > I agree that we should reuse the definition from RFC4796. > > > > Maybe CLUE should change the name of the purpose attribute to content > to follow RFC4796. Avoiding confusion is important. > > > > -Espen > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Roni Even > > Sent: 29. februar 2012 17:39 > > To: 'Paul Kyzivat'; clue@ietf.org > > Subject: Re: [clue] purpose attribute - Review of framework-03 > > > > Hi, > > RFC 4795 defines an attribute that can be used to specify the semantics= of > the stream. The usage is left for application specific document that will > provide the interoperability specification. > > It will be good to use the defined values and the IANA registry since w= e are > also talking in CLUE about multiple streams with different content. > > The framework should explain how to use the values from RFC 4795 Roni > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Wednesday, February 29, 2012 5:48 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] purpose attribute - Review of framework-03 > >> > >> On 2/29/12 9:53 AM, Duckworth, Mark wrote: > >>> Does anybody have a comment or suggestion about this idea? > >>> For the framework document, I'm proposing that instead of defining > >> our own values for the media capture purpose attribute, instead we > >> refer to RFC4796 and use those values that are already defined. > >> > >> It appears 4796 is no less vague about the semantics of the values as > >> we have been so far. And 4796 has an IANA registry and provision to > >> add new values via another RFC, so we can add new ones if we need > > them. > >> > >> But its not enough if we want individual implementations and/or > >> deployments to be able to specify their own values. > >> > >> Note that 4795 allows multiple instances of mediacnt-tag to be > >> attached to a single stream. (E.g. "a=3Dcontent: main, speaker") This > >> could help when more than one apply to the stream. So clue might need > >> to also allow this. > >> > >> Thanks, > >> Paul > >> > >>> Mark > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Duckworth, Mark > >>>> Sent: Monday, February 13, 2012 10:47 AM > >>>> To: Roni Even; clue@ietf.org > >>>> Subject: Re: [clue] purpose attribute - Review of framework-03 > >>>> > >>>> Hi Roni, > >>>> > >>>> Thanks for all the comments. We'll start addressing different > >> topics > >>>> in different email threads. > >>>> > >>>> I was thinking the media capture purpose attribute really should > >> mean > >>>> the same thing as the SDP content attribute in RFC4796. Can CLUE > >>>> just refer to > >>>> RFC4796 for the definition of the purpose attribute values? > >>>> RFC4796 already has an extension mechanism, so we can add new > >>>> values when > >> needed. > >>>> > >>>> Mark > >>>> > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > >>>> Behalf Of Roni Even > >>>> Sent: Wednesday, February 08, 2012 8:49 AM > >>>> To: clue@ietf.org > >>>> Subject: [clue] Review of draft-ietf-clue-framework-03 > >>>> > >>>> 6. In section 6.1.1 I suggest adding one more purpose "SL" for > >>>> sign language indicating that this is the sign language > >>>> representation of the audio stream, see RFC4796. > >>>> > >>>> Thanks > >>>> Roni Even > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Mar 1 16:14:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F53321E81B5 for ; Thu, 1 Mar 2012 16:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTA+HP2wK6Y8 for ; Thu, 1 Mar 2012 16:14:16 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 87AFB21E8011 for ; Thu, 1 Mar 2012 16:14:16 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id gQ3o1i0080EZKEL53QEGB1; Fri, 02 Mar 2012 00:14:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id gQEG1i00P07duvL3MQEGRo; Fri, 02 Mar 2012 00:14:16 +0000 Message-ID: <4F5010D6.7040409@alum.mit.edu> Date: Thu, 01 Mar 2012 19:14:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Duckworth, Mark" References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu> <4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> <4F4FED7A.6090105@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB6C77CC@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C77CC@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 00:14:17 -0000 On 3/1/12 5:33 PM, Duckworth, Mark wrote: > Yes, I agree with Paul, my proposal meant to use the mediacnt values from RFC4796 as the possible values for the "purpose" media capture attribute in CLUE. This attribute wouldn't necessarily be communicated via SDP. > > Somebody else suggested changing the name of the "purpose" attribute to "content", to be a closer match with RFC4796, which sounds good to me. I also suggest allowing multiple values of this per capture. As with a=content, this would mean that the content of the stream has all of these. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Thursday, March 01, 2012 4:43 PM >> To: Christer Holmberg >> Cc: clue@ietf.org >> Subject: Re: [clue] purpose attribute - Review of framework-03 >> >> Christer, >> >> I think the proposal is to adopt the names used in 4296. Then they could be >> used in the content attribute when that makes sense, but also be used in the >> clue-specific messages even if they aren't SDP. >> >> Your point about multiple streams on one m-line applies to many SDP >> elements. >> >> Thanks, >> Paul >> >> On 3/1/12 3:48 PM, Christer Holmberg wrote: >>> >>> Hi, >>> >>> We need to keep in mind, that *IF* we are going to associate multiple >> streams with a single SDP m- line, and each media streams may have a >> different attribute value, many existing values won't work, as they are per >> m- line. >>> >>> So, in this case, what if there are multiple streams associated with the m- >> line, and they all have different languages? >>> >>> The same would apply also to other attributes, e.g. the direction attributes. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Espen Berger (espeberg) >>> Sent: 29. helmikuuta 2012 20:43 >>> To: Roni Even; Paul Kyzivat; clue@ietf.org >>> Subject: Re: [clue] purpose attribute - Review of framework-03 >>> >>> I agree that we should reuse the definition from RFC4796. >>> >>> Maybe CLUE should change the name of the purpose attribute to content >> to follow RFC4796. Avoiding confusion is important. >>> >>> -Espen >>> >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Roni Even >>> Sent: 29. februar 2012 17:39 >>> To: 'Paul Kyzivat'; clue@ietf.org >>> Subject: Re: [clue] purpose attribute - Review of framework-03 >>> >>> Hi, >>> RFC 4795 defines an attribute that can be used to specify the semantics of >> the stream. The usage is left for application specific document that will >> provide the interoperability specification. >>> It will be good to use the defined values and the IANA registry since we are >> also talking in CLUE about multiple streams with different content. >>> The framework should explain how to use the values from RFC 4795 Roni >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Wednesday, February 29, 2012 5:48 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] purpose attribute - Review of framework-03 >>>> >>>> On 2/29/12 9:53 AM, Duckworth, Mark wrote: >>>>> Does anybody have a comment or suggestion about this idea? >>>>> For the framework document, I'm proposing that instead of defining >>>> our own values for the media capture purpose attribute, instead we >>>> refer to RFC4796 and use those values that are already defined. >>>> >>>> It appears 4796 is no less vague about the semantics of the values as >>>> we have been so far. And 4796 has an IANA registry and provision to >>>> add new values via another RFC, so we can add new ones if we need >>> them. >>>> >>>> But its not enough if we want individual implementations and/or >>>> deployments to be able to specify their own values. >>>> >>>> Note that 4795 allows multiple instances of mediacnt-tag to be >>>> attached to a single stream. (E.g. "a=content: main, speaker") This >>>> could help when more than one apply to the stream. So clue might need >>>> to also allow this. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Duckworth, Mark >>>>>> Sent: Monday, February 13, 2012 10:47 AM >>>>>> To: Roni Even; clue@ietf.org >>>>>> Subject: Re: [clue] purpose attribute - Review of framework-03 >>>>>> >>>>>> Hi Roni, >>>>>> >>>>>> Thanks for all the comments. We'll start addressing different >>>> topics >>>>>> in different email threads. >>>>>> >>>>>> I was thinking the media capture purpose attribute really should >>>> mean >>>>>> the same thing as the SDP content attribute in RFC4796. Can CLUE >>>>>> just refer to >>>>>> RFC4796 for the definition of the purpose attribute values? >>>>>> RFC4796 already has an extension mechanism, so we can add new >>>>>> values when >>>> needed. >>>>>> >>>>>> Mark >>>>>> >>>>>> =================================== >>>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>>> Behalf Of Roni Even >>>>>> Sent: Wednesday, February 08, 2012 8:49 AM >>>>>> To: clue@ietf.org >>>>>> Subject: [clue] Review of draft-ietf-clue-framework-03 >>>>>> >>>>>> 6. In section 6.1.1 I suggest adding one more purpose "SL" for >>>>>> sign language indicating that this is the sign language >>>>>> representation of the audio stream, see RFC4796. >>>>>> >>>>>> Thanks >>>>>> Roni Even >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Mar 1 22:16:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4081721F8C32 for ; Thu, 1 Mar 2012 22:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.222 X-Spam-Level: X-Spam-Status: No, score=-10.222 tagged_above=-999 required=5 tests=[AWL=0.377, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v94Tr3dlQgJu for ; Thu, 1 Mar 2012 22:16:55 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E92CE21F8C31 for ; Thu, 1 Mar 2012 22:16:54 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-e0-4f5065d57d32 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FE.57.01970.5D5605F4; Fri, 2 Mar 2012 07:16:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.31]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 2 Mar 2012 07:16:54 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Fri, 2 Mar 2012 07:16:52 +0100 Thread-Topic: [clue] purpose attribute - Review of framework-03 Thread-Index: Acz39FTzjBMFXP6XTTuXAv460joDQgAR5mBw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3F6AB163@ESESSCMS0356.eemea.ericsson.se> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB302369@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0169@CRPMBOXPRD01.polycom.com><4F4E48C3.4020502@alum.mit.edu> <4f4e54c7.cb620e0a.7f4c.ffff8599@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3367@XMB-AMS-214.cisco.com> <96F825286CEAFC40B37C080D4284A44F2C3868104B@ESESSCMS0356.eemea.ericsson.se> <4F4FED7A.6090105@alum.mit.edu> In-Reply-To: <4F4FED7A.6090105@alum.mit.edu> 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 X-Brightmail-Tracker: AAAAAA== Cc: "clue@ietf.org" Subject: Re: [clue] purpose attribute - Review of framework-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 06:16:56 -0000 Hi,=20 > I think the proposal is to adopt the names used in 4296. Then they could = be used in the content=20 > attribute when that makes sense, but also be used in the clue-specific me= ssages even if they aren't SDP. > > Your point about multiple streams on one m-line applies to many SDP eleme= nts. Yes. Regards, Christer On 3/1/12 3:48 PM, Christer Holmberg wrote: > > Hi, > > We need to keep in mind, that *IF* we are going to associate multiple str= eams with a single SDP m- line, and each media streams may have a different= attribute value, many existing values won't work, as they are per m- line. > > So, in this case, what if there are multiple streams associated with the = m- line, and they all have different languages? > > The same would apply also to other attributes, e.g. the direction attribu= tes. > > Regards, > > Christer > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Espen Berger (espeberg) > Sent: 29. helmikuuta 2012 20:43 > To: Roni Even; Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > I agree that we should reuse the definition from RFC4796. > > Maybe CLUE should change the name of the purpose attribute to content to = follow RFC4796. Avoiding confusion is important. > > -Espen > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Roni Even > Sent: 29. februar 2012 17:39 > To: 'Paul Kyzivat'; clue@ietf.org > Subject: Re: [clue] purpose attribute - Review of framework-03 > > Hi, > RFC 4795 defines an attribute that can be used to specify the semantics o= f the stream. The usage is left for application specific document that will= provide the interoperability specification. > It will be good to use the defined values and the IANA registry since we = are also talking in CLUE about multiple streams with different content. > The framework should explain how to use the values from RFC 4795 Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 >> Of Paul Kyzivat >> Sent: Wednesday, February 29, 2012 5:48 PM >> To: clue@ietf.org >> Subject: Re: [clue] purpose attribute - Review of framework-03 >> >> On 2/29/12 9:53 AM, Duckworth, Mark wrote: >>> Does anybody have a comment or suggestion about this idea? >>> For the framework document, I'm proposing that instead of defining >> our own values for the media capture purpose attribute, instead we=20 >> refer to RFC4796 and use those values that are already defined. >> >> It appears 4796 is no less vague about the semantics of the values as=20 >> we have been so far. And 4796 has an IANA registry and provision to=20 >> add new values via another RFC, so we can add new ones if we need > them. >> >> But its not enough if we want individual implementations and/or=20 >> deployments to be able to specify their own values. >> >> Note that 4795 allows multiple instances of mediacnt-tag to be=20 >> attached to a single stream. (E.g. "a=3Dcontent: main, speaker") This=20 >> could help when more than one apply to the stream. So clue might need=20 >> to also allow this. >> >> Thanks, >> Paul >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 >>>> Behalf Of Duckworth, Mark >>>> Sent: Monday, February 13, 2012 10:47 AM >>>> To: Roni Even; clue@ietf.org >>>> Subject: Re: [clue] purpose attribute - Review of framework-03 >>>> >>>> Hi Roni, >>>> >>>> Thanks for all the comments. We'll start addressing different >> topics >>>> in different email threads. >>>> >>>> I was thinking the media capture purpose attribute really should >> mean >>>> the same thing as the SDP content attribute in RFC4796. Can CLUE=20 >>>> just refer to >>>> RFC4796 for the definition of the purpose attribute values? >>>> RFC4796 already has an extension mechanism, so we can add new=20 >>>> values when >> needed. >>>> >>>> Mark >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 >>>> Behalf Of Roni Even >>>> Sent: Wednesday, February 08, 2012 8:49 AM >>>> To: clue@ietf.org >>>> Subject: [clue] Review of draft-ietf-clue-framework-03 >>>> >>>> 6. In section 6.1.1 I suggest adding one more purpose "SL" for=20 >>>> sign language indicating that this is the sign language=20 >>>> representation of the audio stream, see RFC4796. >>>> >>>> Thanks >>>> Roni Even >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From johaniel@cisco.com Fri Mar 2 07:43:00 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4B21F863D for ; Fri, 2 Mar 2012 07:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oh3Cdi5MvkZ for ; Fri, 2 Mar 2012 07:42:56 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 61E2821F8627 for ; Fri, 2 Mar 2012 07:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=21620; q=dns/txt; s=iport; t=1330702975; x=1331912575; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=NfH+AJUNcTLSa1w31hKj24O/X554DiA3c/Acb2J2i1s=; b=mSnmiV2C7rAVtoUYF6O073pprygzVg4ClGLj2gKy7Pviyy1uRwVdF9aE wAnWYKl6OaVxQtarHqQ4tl5zsOn6zVv8YafzFWfmpQjtasoCUVN3uOqhd KxHx0Nn2y2FlTqvq7kxvnhNuYcTPJ0TPKkZwdYiIh1PM8JykvX9KzFgjD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADPpUE+Q/khN/2dsb2JhbABDglKxc4EHgX0BAQEEEgEJEQNCFwIBCBEEAQELBhcBBgEgJQkIAQEEARIIGodkoRcBlxuJIIVhYwSgXIdY X-IronPort-AV: E=Sophos;i="4.73,518,1325462400"; d="scan'208,217";a="131184377" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2012 15:42:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q22Fgs1H005155; Fri, 2 Mar 2012 15:42:54 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 16:42:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCF88B.21CEB3E4" Date: Fri, 2 Mar 2012 16:42:52 +0100 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AEC5B92@XMB-AMS-206.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgABIgOgAAFYB3AAU9pBgA== References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com><4f4eb007.85600e0a.1d16.74b8@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> From: "Johan Ludvig Nielsen (johaniel)" To: "Duckworth, Mark" , "Roni Even" , X-OriginalArrivalTime: 02 Mar 2012 15:42:54.0134 (UTC) FILETIME=[21FE0560:01CCF88B] Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:43:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCF88B.21CEB3E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 I think it would be useful to include audio and connection between audio and video in this discussion.=20 =20 Can the simultaneous or mutually-exclusive sets be used to specify which audio captures can be used with which video captures, and which cannot? =20 This could solve the case in 11.1 where the connection through the capture area is insufficient for some captures, as I have pointed out in an earlier post on the spatial relationships. =20 Regards Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 1. mars 2012 00:48 To: Roni Even; clue@ietf.org Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets =20 Hi, For this example it would be a little simpler like this: VC1 - mutually-exclusive=3D{VC5} VC3 - mutually-exclusive=3D{VC5} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1,VC3,VC4} =20 The point for scalability was to simplify a case like this: VC1 - mutually-exclusive=3D{VC2} VC2 - mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC4} VC4 - mutually-exclusive=3D{VC3} VC5 - mutually-exclusive=3D{VC6} VC6 - mutually-exclusive=3D{VC5} =20 In simultaneous sets it would have been: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 Adding another mutually exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs each. =20 I agree the framework should clarify that capture set entries are the provider's suggestion to the consumer about which media captures would be most useful to receive together. =20 I agree the framework should clarify that the consumer can choose just part of a capture set entry. =20 The consumer can also pick and choose media captures from different capture set entries, and for this case the mutually exclusive information becomes important. =20 Mark =20 =20 =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Wednesday, February 29, 2012 6:08 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simutaneous sets =20 Hi, I do not think that changes anything since this is the complement of the simultaneous set and will be less condensed. For example taking the example from the framework in section 11.1 =20 The physical simultaneity information is: =20 {VC0, VC1, VC2, VC3, VC4, VC6} =20 {VC0, VC2, VC5, VC6} =20 Your proposal will require VC1 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC3} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC4} And the result is the same since it can be translated to the current description. =20 My proposal was to clarify in the framework that the capture set entries are the preferred mode as proposed by the provider. Also to say that a consumer can select part of a capture set entry or simultaneous set. =20 Roni =20 =20 =20 =20 =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets =20 This is a proposal from all the framework authors. Please review. =20 We propose removing the concept of "simultaneous sets" and replacing it with a new media capture attribute called "mutually exclusive". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. This is in response to concerns discussed at the interim meeting about scalability of simultaneous sets, and confusion between simultaneous sets and capture set entries. =20 New Media Capture attribute: =20 Mutually-exclusive: {list of MCs that cannot be used at same time as this MC} =20 Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. =20 The provider specifies this with the following video capture attribute values: VC1 - mutually-exclusive=3D{VC3} VC3 - mutually-exclusive=3D{VC1} =20 A provider must advertise mutually exclusive attributes that allow all the media captures in a capture set entry to be used at the same time. =20 Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather than the simultaneous sets. =20 Mark =20 ------_=_NextPart_001_01CCF88B.21CEB3E4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

I think it would be = useful to include audio and connection between audio and video in this = discussion.

 

Can the = simultaneous  or mutually-exclusive sets be used to specify which = audio captures can be used with which video captures, and which = cannot?

 

This could solve the = case in 11.1 where the connection through the capture area is = insufficient for some captures, as I have pointed out in an earlier post = on the spatial relationships.

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: 1. mars 2012 00:48
To: = Roni Even; clue@ietf.org
Subject: Re: [clue] propose = "mutually exclusive" attribute toreplace simutaneous = sets

 

Hi,

For this example it = would be a little simpler like this:

VC1 – = mutually-exclusive=3D{VC5}

VC3 = – mutually-exclusive=3D{VC5}

VC4 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC1,VC3,VC4}

 

The point for = scalability was to simplify a case like this:

VC1 – = mutually-exclusive=3D{VC2}

VC2 = – mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC4}

VC4 = – mutually-exclusive=3D{VC3}

VC5 – = mutually-exclusive=3D{VC6}

VC6 = – mutually-exclusive=3D{VC5}

 

In simultaneous sets it = would have been:

{VC1, VC3, VC5}

{VC1, VC4, = VC5}

{VC1, VC3, VC6}

{VC1, VC4, = VC6}

{VC2, VC3, VC5}

{VC2, VC4, = VC5}

{VC2, VC3, VC6}

{VC2, VC4, = VC6}

 

Adding another mutually = exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs = each.

 

I agree the framework = should clarify that capture set entries are the provider’s = suggestion to the consumer about which media captures would be most = useful to receive together.

 

I agree the framework = should clarify that the consumer can choose just part of a capture set = entry.

 

The consumer can also = pick and choose media captures from different capture set entries, and = for this case the mutually exclusive information becomes = important.

 

Mark

 

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Wednesday, February 29, 2012 6:08 PM
To: = Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

Hi,

I do not think = that changes anything since this is the complement of the simultaneous = set and will be less condensed.

For = example taking the example from the framework in section = 11.1

 

  = ; The physical simultaneity information is:

 =

  = ;    {VC0, VC1, VC2, VC3, VC4, = VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Your = proposal will require

VC1 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC3}

VC4 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC4}

And the result is the same since it can be translated = to the current description.

 

My proposal = was to clarify in the framework that  the capture set entries are = the preferred mode as proposed by the provider. Also to say that a = consumer can select part of a capture set entry or simultaneous = set.

 

Roni

 

 

 =

 =

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Thursday, March 01, = 2012 12:43 AM
To: clue@ietf.org
Subject: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

This is a = proposal from all the framework authors.  Please = review.

 

We propose removing the concept of “simultaneous = sets” and replacing it with a new media capture attribute called = “mutually exclusive”.  The purpose is to have a more = concise way to indicate which media captures cannot be used at the same = time, which we believe scales better than the simultaneous set idea when = there are multiple mutually exclusive constraints.  This is in = response to concerns discussed at the interim meeting about scalability = of simultaneous sets, and confusion between simultaneous sets and = capture set entries.

 

New Media = Capture attribute:

 

Mutually-exclusive: {list of MCs that cannot be used = at same time as this MC}

 

Consider the = example of a room system where there are 3 cameras each

of which can send a separate capture covering 2 = persons each- VC0,

VC1, VC2. The = middle camera can also zoom out and show all 6

persons, VC3. But the middle camera cannot be used in = both modes at

the same time - it has = to either show the space where 2 participants

sit or the whole 6 seats, but not both at the same = time.

 

The provider specifies this with the following video = capture attribute values:

VC1 – = mutually-exclusive=3D{VC3}

VC3 = – mutually-exclusive=3D{VC1}

 

A provider = must advertise mutually exclusive attributes that allow all the media = captures in a capture set entry to be used at the same = time.

 

Section 6.3 “Simultaneous Transmission Set = Constraints” can be removed.

We = will update the example in section 11.1 to show the new attribute rather = than the simultaneous sets.

 

Mark

 

------_=_NextPart_001_01CCF88B.21CEB3E4-- From ron.even.tlv@gmail.com Fri Mar 2 11:53:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B797921E8071 for ; Fri, 2 Mar 2012 11:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgT5JbiYAb+S for ; Fri, 2 Mar 2012 11:52:59 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CEE7A21E806E for ; Fri, 2 Mar 2012 11:52:58 -0800 (PST) Received: by eeke51 with SMTP id e51so729617eek.31 for ; Fri, 02 Mar 2012 11:52:52 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.48.77 as permitted sender) client-ip=10.14.48.77; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.48.77 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.48.77]) by 10.14.48.77 with SMTP id u53mr6859900eeb.0.1330717972742 (num_hops = 1); Fri, 02 Mar 2012 11:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=e/FMZhuZsM7F3e/VBoAEDZQLlliKfr5mkTksVJne33U=; b=zgBZuJ/FpoD60O7AzFhzkcd0oFqB1PG30uvoy1xbsLqAy/0Cu/8yvm2F4L7VVv4oN7 s49RtxVw7MlwlsZLtm6nl+Y9oepUiwmMiFP8c/b45t+bAMdKMHLRJOJdwaryhTOcaJeo VsUg509foPDKLILO6UgfbpSrrxN+zzviaj6OT6tYII+Y8fe9RaBa7S8MxGwEArn7PVBU 6zF1VWY/e2uHC1OSGnlRouBe+MVNp9eQoEK3e9FapNKpYN0TRqz+z3IgZPuOR+BlGxBi wrHPjpESZ6lIMbKbRd4bCBL/z1umzT0i9uMQvc8YygEgBgnsCL4kemqu1nS1Zxl0VYwf 4gzg== Received: by 10.14.48.77 with SMTP id u53mr5278828eeb.0.1330717972575; Fri, 02 Mar 2012 11:52:52 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id c15sm23960243eei.9.2012.03.02.11.52.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 02 Mar 2012 11:52:51 -0800 (PST) From: "Roni Even" To: "'Johan Ludvig Nielsen \(johaniel\)'" , "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com><4f4eb007.85600e0a.1d16.74b8@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> <05DD269BD82AA549BC4B2619BBAC466AEC5B92@XMB-AMS-206.cisco.com> In-Reply-To: <05DD269BD82AA549BC4B2619BBAC466AEC5B92@XMB-AMS-206.cisco.com> Date: Fri, 2 Mar 2012 21:51:55 +0200 Message-ID: <4f512513.0f7f0e0a.6652.52d6@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0587_01CCF8BE.B0EEB390" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgABIgOgAAFYB3AAU9pBgAAIs9Qw Content-Language: en-us Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:53:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0587_01CCF8BE.B0EEB390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The simultaneous discussion is about describing physical constrains while audio and video connection is application connection. I am not sure if the audio video should be part of the physical constrains. Also note that the SDP grouping already provides for it, but if you want it in CLUE it should be s different attribute. Roni Even From: Johan Ludvig Nielsen (johaniel) [mailto:johaniel@cisco.com] Sent: Friday, March 02, 2012 5:43 PM To: Duckworth, Mark; Roni Even; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets Hi I think it would be useful to include audio and connection between audio and video in this discussion. Can the simultaneous or mutually-exclusive sets be used to specify which audio captures can be used with which video captures, and which cannot? This could solve the case in 11.1 where the connection through the capture area is insufficient for some captures, as I have pointed out in an earlier post on the spatial relationships. Regards Johan From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 1. mars 2012 00:48 To: Roni Even; clue@ietf.org Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets Hi, For this example it would be a little simpler like this: VC1 - mutually-exclusive={VC5} VC3 - mutually-exclusive={VC5} VC4 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC1,VC3,VC4} The point for scalability was to simplify a case like this: VC1 - mutually-exclusive={VC2} VC2 - mutually-exclusive={VC1} VC3 - mutually-exclusive={VC4} VC4 - mutually-exclusive={VC3} VC5 - mutually-exclusive={VC6} VC6 - mutually-exclusive={VC5} In simultaneous sets it would have been: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} Adding another mutually exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs each. I agree the framework should clarify that capture set entries are the provider's suggestion to the consumer about which media captures would be most useful to receive together. I agree the framework should clarify that the consumer can choose just part of a capture set entry. The consumer can also pick and choose media captures from different capture set entries, and for this case the mutually exclusive information becomes important. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Wednesday, February 29, 2012 6:08 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simutaneous sets Hi, I do not think that changes anything since this is the complement of the simultaneous set and will be less condensed. For example taking the example from the framework in section 11.1 The physical simultaneity information is: {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Your proposal will require VC1 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC1} VC3 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC3} VC4 - mutually-exclusive={VC5} VC5- mutually-exclusive={VC4} And the result is the same since it can be translated to the current description. My proposal was to clarify in the framework that the capture set entries are the preferred mode as proposed by the provider. Also to say that a consumer can select part of a capture set entry or simultaneous set. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets This is a proposal from all the framework authors. Please review. We propose removing the concept of "simultaneous sets" and replacing it with a new media capture attribute called "mutually exclusive". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. This is in response to concerns discussed at the interim meeting about scalability of simultaneous sets, and confusion between simultaneous sets and capture set entries. New Media Capture attribute: Mutually-exclusive: {list of MCs that cannot be used at same time as this MC} Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. The provider specifies this with the following video capture attribute values: VC1 - mutually-exclusive={VC3} VC3 - mutually-exclusive={VC1} A provider must advertise mutually exclusive attributes that allow all the media captures in a capture set entry to be used at the same time. Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather than the simultaneous sets. Mark ------=_NextPart_000_0587_01CCF8BE.B0EEB390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The simultaneous = discussion is about describing physical constrains while audio and video = connection is application connection.

I am not sure if the = audio video should be part of the physical constrains. Also note that = the SDP grouping already provides for it, but if you want it in CLUE it = should be s different attribute.

Roni = Even

 

From:= = Johan Ludvig Nielsen (johaniel) [mailto:johaniel@cisco.com] =
Sent: Friday, March 02, 2012 5:43 PM
To: Duckworth, = Mark; Roni Even; clue@ietf.org
Subject: RE: [clue] propose = "mutually exclusive" attribute toreplace simutaneous = sets

 

Hi

 

I think it would be = useful to include audio and connection between audio and video in this = discussion.

 

Can the = simultaneous  or mutually-exclusive sets be used to specify which = audio captures can be used with which video captures, and which = cannot?

 

This could solve the = case in 11.1 where the connection through the capture area is = insufficient for some captures, as I have pointed out in an earlier post = on the spatial relationships.

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: 1. mars 2012 = 00:48
To: Roni Even; clue@ietf.org
Subject: Re: = [clue] propose "mutually exclusive" attribute toreplace = simutaneous sets

 

Hi,

For this example it = would be a little simpler like this:

VC1 – = mutually-exclusive=3D{VC5}

VC3 = – mutually-exclusive=3D{VC5}

VC4 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC1,VC3,VC4}

 

The point for = scalability was to simplify a case like this:

VC1 – = mutually-exclusive=3D{VC2}

VC2 = – mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC4}

VC4 = – mutually-exclusive=3D{VC3}

VC5 – = mutually-exclusive=3D{VC6}

VC6 = – mutually-exclusive=3D{VC5}

 

In simultaneous sets it = would have been:

{VC1, VC3, VC5}

{VC1, VC4, = VC5}

{VC1, VC3, VC6}

{VC1, VC4, = VC6}

{VC2, VC3, VC5}

{VC2, VC4, = VC5}

{VC2, VC3, VC6}

{VC2, VC4, = VC6}

 

Adding another mutually = exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs = each.

 

I agree the framework = should clarify that capture set entries are the provider’s = suggestion to the consumer about which media captures would be most = useful to receive together.

 

I agree the framework = should clarify that the consumer can choose just part of a capture set = entry.

 

The consumer can also = pick and choose media captures from different capture set entries, and = for this case the mutually exclusive information becomes = important.

 

Mark

 

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Wednesday, February 29, 2012 6:08 PM
To: = Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

Hi,

I do not think = that changes anything since this is the complement of the simultaneous = set and will be less condensed.

For = example taking the example from the framework in section = 11.1

 

  = ; The physical simultaneity information is:

 =

  = ;    {VC0, VC1, VC2, VC3, VC4, = VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Your = proposal will require

VC1 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC3}

VC4 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC4}

And the result is the same since it can be translated = to the current description.

 

My proposal = was to clarify in the framework that  the capture set entries are = the preferred mode as proposed by the provider. Also to say that a = consumer can select part of a capture set entry or simultaneous = set.

 

Roni

 

 

 =

 =

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Thursday, March 01, = 2012 12:43 AM
To: clue@ietf.org
Subject: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

This is a = proposal from all the framework authors.  Please = review.

 

We propose removing the concept of “simultaneous = sets” and replacing it with a new media capture attribute called = “mutually exclusive”.  The purpose is to have a more = concise way to indicate which media captures cannot be used at the same = time, which we believe scales better than the simultaneous set idea when = there are multiple mutually exclusive constraints.  This is in = response to concerns discussed at the interim meeting about scalability = of simultaneous sets, and confusion between simultaneous sets and = capture set entries.

 

New Media = Capture attribute:

 

Mutually-exclusive: {list of MCs that cannot be used = at same time as this MC}

 

Consider the = example of a room system where there are 3 cameras each

of which can send a separate capture covering 2 = persons each- VC0,

VC1, VC2. The = middle camera can also zoom out and show all 6

persons, VC3. But the middle camera cannot be used in = both modes at

the same time - it has = to either show the space where 2 participants

sit or the whole 6 seats, but not both at the same = time.

 

The provider specifies this with the following video = capture attribute values:

VC1 – = mutually-exclusive=3D{VC3}

VC3 = – mutually-exclusive=3D{VC1}

 

A provider = must advertise mutually exclusive attributes that allow all the media = captures in a capture set entry to be used at the same = time.

 

Section 6.3 “Simultaneous Transmission Set = Constraints” can be removed.

We = will update the example in section 11.1 to show the new attribute rather = than the simultaneous sets.

 

Mark

 

------=_NextPart_000_0587_01CCF8BE.B0EEB390-- From Mark.Duckworth@polycom.com Mon Mar 5 10:25:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EEC21F87EC for ; Mon, 5 Mar 2012 10:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.608 X-Spam-Level: X-Spam-Status: No, score=-5.608 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY-F3OL6oAXZ for ; Mon, 5 Mar 2012 10:25:43 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 95D5721F8775 for ; Mon, 5 Mar 2012 10:25:43 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 5 Mar 2012 10:25:42 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 5 Mar 2012 10:25:40 -0800 Thread-Topic: Ticket #7 composed attribute Thread-Index: Acz6/MLPU1dr3btARqORYI12DkPslg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Ticket #7 composed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:25:44 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From the interim meeting minutes: "3.2.6 Is "Composed" a Boolean, or a data structure? Based on previous issu= e - Boolean is as far as CLUE should go." My recollection is that the people in the meeting generally agreed on this.= So it seems to me this is the resolution of ticket #7. Is that correct? Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From the interim= meeting minutes:

“3.2.6 Is “Composed” a Boolean, = or a data structure? Based on previous issue – Boolean is as far as C= LUE should go.”

 

My recollection is that the people in the meeting generally agreed= on this.  So it seems to me this is the resolution of ticket #7. = ; Is that correct?

 

Mark

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93CRPMBOXPRD01p_-- From Mark.Duckworth@polycom.com Mon Mar 5 10:29:28 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0994E21F8794 for ; Mon, 5 Mar 2012 10:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKEt+AJDATki for ; Mon, 5 Mar 2012 10:29:27 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC821F8764 for ; Mon, 5 Mar 2012 10:29:27 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 5 Mar 2012 10:29:27 -0800 From: "Duckworth, Mark" To: Paul Kyzivat Date: Mon, 5 Mar 2012 10:29:24 -0800 Thread-Topic: [clue] Language re capture axis Thread-Index: Acz39bmzi3xp5IYOTlqtynCdqtIghADB8pJw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F9F@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> <4F4E4A81.6070006@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> <4F4FEFCD.7000806@alum.mit.edu> In-Reply-To: <4F4FEFCD.7000806@alum.mit.edu> 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 Cc: "clue@ietf.org" Subject: Re: [clue] Language re capture axis X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:29:28 -0000 As editor, it seems I should leave this out of the next version. Okay? Otherwise, I would appreciate having interested parties propose new text to= discuss on the mailing list, considering Paul's desire to have more specif= ic text than what we have previously discussed. Thanks, Mark > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, March 01, 2012 4:53 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] Language re capture axis >=20 > On 2/29/12 11:14 AM, Duckworth, Mark wrote: > > Paul and Stephan, > > > > Personally, I'd rather just leave it out altogether because I think it = doesn't > add anything that needs to be standardized. But Stephan thought it was > important, so I was trying to find a way to say it in an "accurate enough= " way. >=20 > If there is no widespread interest in having this, and those who have ask= ed > about it are happy without, then I'm fine with leaving it out. >=20 > If it is to be mentioned, with the idea that the recipient might use it f= or > something, then I think it should be made clear how it can be determined. >=20 > Thanks, > Paul >=20 > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Paul Kyzivat > >> Sent: Wednesday, February 29, 2012 10:56 AM > >> To: clue@ietf.org > >> Subject: Re: [clue] Language re capture axis > >> > >> On 2/29/12 10:10 AM, Duckworth, Mark wrote: > >>> Hi Stephan, > >>> > >>> I agree in principle with your suggestion, but I think your > >>> suggested text is not mathematically accurate. I think the axis of > >>> capture doesn't go to the center of the area of capture. For > >>> example, if the camera is pointed at the area of capture at an > >>> angle, the center point of the area would not line up with the > >>> center point of the camera's field of view (which defines the axis). > >>> > >>> So rather than try to get into the mathematical details, how about th= is: > >>> > >>> "Note that, for the purpose of receiver-side geometric correction, > >>> it can be assumed that the axis of capture of directional capture > >>> devices (cameras, directional microphones etc.) can be calculated > >>> from the coordinates of the point of capture and area of capture." > >> > >> IMO this is dangerously vague. Presumably there is a real axis of capt= ure. > >> Hopefully there is a well defined algorithm for deriving the axis > >> from the available data, so that the recipient will determine the > >> actual axis. If so, then it should be specified or referenced from > >> some source. Otherwise we run the risk that not all will correctly der= ive > the axis. > >> > >> Thanks, > >> Paul > >> > >>> Mark > >>> > >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > >>> Behalf Of *Stephan Wenger > >>> *Sent:* Wednesday, February 15, 2012 11:04 AM > >>> *To:* clue@ietf.org > >>> *Subject:* [clue] Language re capture axis > >>> > >>> Hi, > >>> > >>> The issue I mentioned in the meeting is that nowhere in the > >>> framework (as far as I recall) the axis of capture of a video > >>> capture (or directional audio capture-anything that is not > >>> omnidirectional) is undefined. Without that axis being defined, > >>> receiver-side geometric correction is not possible. > >>> > >>> The issue could be solved in two ways: include attributes, per > >>> capture, indicating angle of capture in 3D space (relative to > >>> what???), or by making the bold assumption that the coordinates > >>> defining area of capture plus capture point define the axis of > >>> capture. I suggest the latter as it is easy to implement and (I > >>> believe) > >> practical. > >>> > >>> The language could be something like: > >>> > >>> " > >>> > >>> Note that, for the purpose of receiver-side geometric correction, it > >>> can be assumed that the axis of capture of directional capture > >>> devices (cameras, directional microphones etc.) is the line from the > >>> capture point to the center of the plane of capture. > >>> > >>> " > >>> > >>> Stephan > >>> > >>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > From Even.roni@huawei.com Mon Mar 5 10:37:25 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D97A21F88E7 for ; Mon, 5 Mar 2012 10:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.585 X-Spam-Level: X-Spam-Status: No, score=-106.585 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-SzgooNtMyx for ; Mon, 5 Mar 2012 10:37:24 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBD621F88E8 for ; Mon, 5 Mar 2012 10:37:24 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0F009STCTMGJ@szxga03-in.huawei.com> for clue@ietf.org; Tue, 06 Mar 2012 02:32:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0F000MFCSUPO@szxga03-in.huawei.com> for clue@ietf.org; Tue, 06 Mar 2012 02:32:10 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHG20489; Tue, 06 Mar 2012 02:32:03 +0800 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 02:31:46 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Tue, 06 Mar 2012 02:31:59 +0800 Date: Mon, 05 Mar 2012 18:31:59 +0000 From: Roni even In-reply-to: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> X-Originating-IP: [172.24.1.46] To: "Duckworth, Mark" , "clue@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Vfvfm4DD33FELn5XxSujfQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Ticket #7 composed attribute Thread-index: Acz6/MLPU1dr3btARqORYI12DkPslgAAUI6h X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> Subject: Re: [clue] Ticket #7 composed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:37:25 -0000 --Boundary_(ID_Vfvfm4DD33FELn5XxSujfQ) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Hi Mark, This is not my recollection. It is OK to have a Boolean as long as we have = an attribute that provide information about the composition in the framewor= k document or we need to change the composed attribute. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Monday, March 05, 2012 20:25 To: clue@ietf.org Subject: [clue] Ticket #7 composed attribute >From the interim meeting minutes: =933.2.6 Is =93Composed=94 a Boolean, or a data structure? Based on previou= s issue =96 Boolean is as far as CLUE should go.=94 My recollection is that the people in the meeting generally agreed on this.= So it seems to me this is the resolution of ticket #7. Is that correct? Mark --Boundary_(ID_Vfvfm4DD33FELn5XxSujfQ) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Hi Mark,

This is not my recollection. It is OK to have a Boolean as long as we ha= ve an attribute that provide information about the composition = in the framework document or we need to change the composed attribute.

 

Roni

From: clue-bounces@ietf.org [clue-bounces@i= etf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Monday, March 05, 2012 20:25
To: clue@ietf.org
Subject: [clue] Ticket #7 composed attribute

From the interim meeting minutes:

=933.2.6 Is =93Composed= =94 a Boolean, or a data structure? Based on previous issue =96 Boolean is = as far as CLUE should go.=94

 

My recollection is that the people in the meeting ge= nerally agreed on this.  So it seems to me this is the resolution of t= icket #7.  Is that correct?

 

Mark

 

--Boundary_(ID_Vfvfm4DD33FELn5XxSujfQ)-- From ron.even.tlv@gmail.com Mon Mar 5 10:48:18 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435F721F8908 for ; Mon, 5 Mar 2012 10:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYQOb1td8bsv for ; Mon, 5 Mar 2012 10:48:17 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D129A21F87D6 for ; Mon, 5 Mar 2012 10:48:16 -0800 (PST) Received: by eaaq11 with SMTP id q11so1517871eaa.31 for ; Mon, 05 Mar 2012 10:48:16 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.119.194 as permitted sender) client-ip=10.14.119.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.119.194 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.119.194]) by 10.14.119.194 with SMTP id n42mr11820481eeh.113.1330973296147 (num_hops = 1); Mon, 05 Mar 2012 10:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=h92PdVtKNjc08RRi5YAjfiAz21zr83MlA316lpVvqoM=; b=bEsFZFwPqAfIKZ/X8OHgDX55H1X22W9BV9O5LeKWYdXrhlWgxRzjSWbGPH/W1Vr34/ DtXCLecWj6esewicS2nZPY3yiR65EAA5fX5eLJtSEoIHk5g/mU7pHi0337D6BGR4GzY9 yaYQ8KX7+YbcIkKjlkA3XQ39DM8sAXHqwcPigEebryr+tOKNJ50ZjKbiPV/omwgsprZi TsP2boIQpnn4evYx6Tf0L3htqJG8quNbWj7YNKqMqBixqtRYG84r3hOrPMWpCY1Vw6m0 8mjISKUraF2xyRKmpB56oJsnceVaP1pdPlkTq31VpQDYm0dk52M+CipjnFv+VKnWf6QZ zlSw== Received: by 10.14.119.194 with SMTP id n42mr8989092eeh.113.1330973296082; Mon, 05 Mar 2012 10:48:16 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id v51sm64395762eef.2.2012.03.05.10.48.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 10:48:15 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> Date: Mon, 5 Mar 2012 20:47:10 +0200 Message-ID: <4f550a6f.cb620e0a.3e2d.488d@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_063C_01CCFB11.243216E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz6/MLPU1dr3btARqORYI12DkPslgAAx7cA Content-Language: en-us Subject: Re: [clue] Ticket #7 composed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:48:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_063C_01CCFB11.243216E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I did not support this and this was added to the action item when I was not present. The discussion in the meeting was about allowing the provider to offer more than one composed option that will allow the consumer to select from. There was no agreement during the session as far as I can see from the notes and the summary does not reflect the discussion. BTW: These are rough notes and there is no meeting summary yet from the WG chairs Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 05, 2012 8:26 PM To: clue@ietf.org Subject: [clue] Ticket #7 composed attribute >From the interim meeting minutes: "3.2.6 Is "Composed" a Boolean, or a data structure? Based on previous issue - Boolean is as far as CLUE should go." My recollection is that the people in the meeting generally agreed on this. So it seems to me this is the resolution of ticket #7. Is that correct? Mark ------=_NextPart_000_063C_01CCFB11.243216E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I did not support this = and this was added to the action item when I was not = present.

The discussion in the meeting was about allowing = the provider to offer more than one composed option that will allow the = consumer to select from. There was no agreement during the session as = far as I can see from the notes and the summary does not reflect the = discussion.

BTW: These are rough notes and there is no = meeting summary yet from the WG chairs

Roni = Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Monday, March 05, 2012 8:26 = PM
To: clue@ietf.org
Subject: [clue] Ticket #7 = composed attribute

 

From the = interim meeting minutes:

“3.2.6 Is = “Composed” a Boolean, or a data structure? Based on previous = issue – Boolean is as far as CLUE should = go.”

 

My recollection is that the people in the = meeting generally agreed on this.  So it seems to me this is the = resolution of ticket #7.  Is that correct?

 

Mark

 

------=_NextPart_000_063C_01CCFB11.243216E0-- From Mark.Duckworth@polycom.com Mon Mar 5 11:16:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CE921F8902 for ; Mon, 5 Mar 2012 11:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1XSA7rypA-5 for ; Mon, 5 Mar 2012 11:16:29 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6B19A21F88C2 for ; Mon, 5 Mar 2012 11:16:29 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 5 Mar 2012 11:16:28 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 5 Mar 2012 11:16:26 -0800 Thread-Topic: Proposal to combine capture scene and capture set Thread-Index: Acz7BEjU/dWlSEAnQuC91hY5WY2g+g== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:16:31 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the interim meeting, there was some support for combining the concepts o= f "capture scene" and "capture set" into a single concept. So here is a ro= ugh proposal for doing that, essentially using the term "capture scene" to = replace the previous term "capture set", and eliminating the original separ= ate capture scene concept. Definitions: *Capture Scene: a structure representing the scene that is captured by a co= llection of capture devices. A capture scene includes one or more capture = scene entries, with each entry including one or more media captures. *Capture Scene Entry: a list of media captures of the same media type that = together form one way to represent the capture scene. Text for section 6.2 Capture Scene (was 6.2 Capture Set): A capture scene represents, for example, the video image of a group of peop= le seated next to each other, along with the sound of their voices, which c= ould be represented by some number of VCs and ACs in the capture scene entr= ies. A middle box may also express capture scenes that it constructs from m= edia streams it receives. A media provider arranges media captures in a capture scene to help the med= ia consumer choose which captures it wants. The capture scene entries in a= capture scene are different alternatives the provider is suggesting for re= presenting the capture scene. The media consumer can choose to receive all= media captures from one capture scene entry for each media type (e.g. audi= o and video), or it can pick and choose media captures regardless of how th= e provider arranges them in capture scene entries. A capture scene may include more than one type of media. For example, a ca= pture scene can include several capture scene entries for video captures, a= nd several capture scene entries for audio captures. (This text would be worked into section 6.2, not replace it completely. Ot= her things in section 6.2 and elsewhere would need to be edited to be consi= stent with the new terminology in this proposal) Regards, Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the interim m= eeting, there was some support for combining the concepts of “capture= scene” and “capture set” into a single concept.  So= here is a rough proposal for doing that, essentially using the term “= ;capture scene” to replace the previous term “capture set”= ;, and eliminating the original separate capture scene concept.<= /p>

 

Definitio= ns:

 

*Capture Scene: a structure representing the scene that is captured b= y a collection of capture devices.  A capture scene includes one or mo= re capture scene entries, with each entry including one or more media captu= res. 

 

*Capture Scene Entry: a list of media captures of the same me= dia type that together form one way to represent the capture scene.

 

Text = for section 6.2 Capture Scene (was 6.2 Capture Set):

 

A capture scene repr= esents, for example, the video image of a group of people seated next to ea= ch other, along with the sound of their voices, which could be represented = by some number of VCs and ACs in the capture scene entries. A middle box ma= y also express capture scenes that it constructs from media streams it rece= ives.

 

A media provider arranges media captures in a capture scene to help= the media consumer choose which captures it wants.  The capture scene= entries in a capture scene are different alternatives the provider is sugg= esting for representing the capture scene.  The media consumer can cho= ose to receive all media captures from one capture scene entry for each med= ia type (e.g. audio and video), or it can pick and choose media captures re= gardless of how the provider arranges them in capture scene entries.

 

A ca= pture scene may include more than one type of media.  For example, a c= apture scene can include several capture scene entries for video captures, = and several capture scene entries for audio captures. 

=

 

(This text w= ould be worked into section 6.2, not replace it completely.  Other thi= ngs in section 6.2 and elsewhere would need to be edited to be consistent w= ith the new terminology in this proposal)

 

Regards,

Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008CRPMBOXPRD01p_-- From Mark.Duckworth@polycom.com Mon Mar 5 11:51:25 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC86421F8944 for ; Mon, 5 Mar 2012 11:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY0EX2KUdjKG for ; Mon, 5 Mar 2012 11:51:24 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8334321F8941 for ; Mon, 5 Mar 2012 11:51:21 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 5 Mar 2012 11:51:20 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 5 Mar 2012 11:51:19 -0800 Thread-Topic: switch-policy attribute proposal Thread-Index: Acz7CVVv4KEEqhZGQBGw2/oY+gJ9ZQ== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C805B@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C805BCRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] switch-policy attribute proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:51:26 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C805BCRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At the interim meeting I think people generally agreed the clue framework s= hould include a way for a provider to advertise site-switching and segment-= switching policies, and for the consumer to request one or the other. Here= is a rough proposal. Add a new "switch-policy" attribute for a capture scene entry (or capture s= et entry, using the framework-03 terminology) (note the attribute is for a = capture scene entry not a media capture). Switch-policy: {site-switch, segment-switch} An attribute with enumerated values which identifies the policy the provide= r uses for how to switch the various media captures within the capture scen= e entry. A value of 'site-switch' means all the media captures within the capture sc= ene entry typically switch together, with the provider attempting to includ= e all the media captures from the same site together. A value of 'segment-switch' means the media captures in the entry switch in= dependently of each other, so at any point in time the media captures could= be originally sourced from different sites. In a provider advertisement, the provider can include multiple values for t= he switch-policy attribute. The provider is saying it can provide any one = of those switch-policies it advertises. When a consumer configures the pro= vider, the consumer includes this attribute with only the single value for = switch-policy that it wants to receive. Regards, Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C805BCRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At the interim m= eeting I think people generally agreed the clue framework should include a = way for a provider to advertise site-switching and segment-switching polici= es, and for the consumer to request one or the other.  Here is a rough= proposal.

 

Add a new “switch-policy” attribute for a capture = scene entry (or capture set entry, using the framework-03 terminology) (not= e the attribute is for a capture scene entry not a media capture).

 

Switch= -policy: {site-switch, segment-switch}

A= n attribute with enumerated values which identifies the policy the provider= uses for how to switch the various media captures within the capture scene= entry.

A value of ‘site-switch= 217; means all the media captures within the capture scene entry typically = switch together, with the provider attempting to include all the media capt= ures from the same site together.

A valu= e of ‘segment-switch’ means the media captures in the entry swi= tch independently of each other, so at any point in time the media captures= could be originally sourced from different sites.

 

In a provider advert= isement, the provider can include multiple values for the switch-policy att= ribute.  The provider is saying it can provide any one of those switch= -policies it advertises.  When a consumer configures the provider, the= consumer includes this attribute with only the single value for switch-pol= icy that it wants to receive.

 = ;

Regards,

Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB6C805BCRPMBOXPRD01p_-- From espeberg@cisco.com Mon Mar 5 14:21:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CC421E8035 for ; Mon, 5 Mar 2012 14:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.206 X-Spam-Level: X-Spam-Status: No, score=-10.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeRd7jnefs5I for ; Mon, 5 Mar 2012 14:21:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 71F4821E803D for ; Mon, 5 Mar 2012 14:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=12663; q=dns/txt; s=iport; t=1330986074; x=1332195674; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=YIiDDSX91fJ8tZqEFdUh7CC7/9ilhfLQp7orzfKA7Zo=; b=dVYOEBMeF/0UYdi5FIWBVullvqewf+PGmGauwdaEqhvjkk2if9Hd691F uOna+cWlgljxWvh2VF7nPnOmk/qAhmmw9SbT1NXotN3EqUbmxi3FLSWiq ZVwq4X/h1Zs7HgM+OPIZA4TtY0yvJ3oyXsnN6GSn8kBcymUxzlG2UbdAd 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcFAIs7VU+Q/khN/2dsb2JhbABDgkWpEwGJDoEHgX0BAQEEEgEJEQNZAgEIDgMEAQELBhcBBgFFCQgBAQQBEggah2ULmU8BnnKPbGMEpVCCZA X-IronPort-AV: E=Sophos;i="4.73,536,1325462400"; d="scan'208,217";a="131397504" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2012 22:21:13 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q25MLDHR025983; Mon, 5 Mar 2012 22:21:13 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 23:21:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFB1E.45EE08A3" Date: Mon, 5 Mar 2012 23:20:12 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9EFC3928@XMB-AMS-214.cisco.com> In-Reply-To: <4f550a6f.cb620e0a.3e2d.488d@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Ticket #7 composed attribute Thread-Index: Acz6/MLPU1dr3btARqORYI12DkPslgAAx7cAAAc8xbA= References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> <4f550a6f.cb620e0a.3e2d.488d@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , "Duckworth, Mark" , X-OriginalArrivalTime: 05 Mar 2012 22:21:13.0222 (UTC) FILETIME=[4632B260:01CCFB1E] Subject: Re: [clue] Ticket #7 composed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:21:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB1E.45EE08A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 During the discussions we did not find any clear use case that must be handled in CLUE that involves more than announcing a single composited alternative. Even if there are use cases where that could be possible we discussed them as outside out the scope of version 1 of CLUE.=20 =20 One example we decided to keep out was the video layout as specified in the XCON data model [1]. As presented multiple video-layout alternative can be listed as a single multi value attribute with all options listed and still keep the number of captures the same.=20 =20 The example use case we used where a triple camera system that can do, I only list the single capture alternatives.=20 a) A manually selected alternative, left, center or right=20 b) A switched alternative; based on voice activity=20 c) A composited alternative; by media source choosing.=20 =20 In this case its sufficient to use a flag to separate alternative b and c, and we concluded that a basic flag was sufficient. Vendors are free to extend on the basic model with more details if they think that is needed.=20 =20 -Espen=20 [1] http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-32 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 5. mars 2012 19:47 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Ticket #7 composed attribute =20 Hi, I did not support this and this was added to the action item when I was not present. The discussion in the meeting was about allowing the provider to offer more than one composed option that will allow the consumer to select from. There was no agreement during the session as far as I can see from the notes and the summary does not reflect the discussion. BTW: These are rough notes and there is no meeting summary yet from the WG chairs Roni Even =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 05, 2012 8:26 PM To: clue@ietf.org Subject: [clue] Ticket #7 composed attribute =20 >From the interim meeting minutes: "3.2.6 Is "Composed" a Boolean, or a data structure? Based on previous issue - Boolean is as far as CLUE should go." =20 My recollection is that the people in the meeting generally agreed on this. So it seems to me this is the resolution of ticket #7. Is that correct? =20 Mark =20 ------_=_NextPart_001_01CCFB1E.45EE08A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

During the discussions = we did not find any clear use case that must be handled in CLUE that = involves more than announcing a single composited alternative. Even if = there are use cases where that could be possible we discussed them as = outside out the scope of version 1 of CLUE.

 

One example we decided = to keep out was the video layout as specified in the XCON data model = [1]. As presented multiple video-layout alternative can be listed as a = single multi value attribute with all options listed and still keep the = number of captures the same.

 

The example use case we = used where a triple camera system that can do, I only list the single = capture alternatives.

a)      = A manually = selected alternative, left, center or right

b)      = A switched = alternative; based on voice activity

c)       = A = composited alternative; by media source choosing. =

 

In this case its = sufficient to use a flag to separate alternative b and c, and we = concluded that a basic flag was sufficient. Vendors are free to extend = on the basic model with more details if they think that is needed. =

 

-Espen =

[1] = http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-32

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: 5. mars 2012 19:47
To: = 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Ticket #7 = composed attribute

 

Hi,

I did not = support this and this was added to the action item when I was not = present.

The discussion in the meeting was about allowing = the provider to offer more than one composed option that will allow the = consumer to select from. There was no agreement during the session as = far as I can see from the notes and the summary does not reflect the = discussion.

BTW: These are rough notes and there is no = meeting summary yet from the WG chairs

Roni = Even

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Monday, March 05, = 2012 8:26 PM
To: clue@ietf.org
Subject: = [clue] Ticket #7 composed attribute

 

From the interim meeting = minutes:

“3.2.6 Is “Composed” a Boolean, or a data = structure? Based on previous issue – Boolean is as far as CLUE = should go.”

 

My recollection is that = the people in the meeting generally agreed on this.  So it seems to = me this is the resolution of ticket #7.  Is that = correct?

 

Mark

 

------_=_NextPart_001_01CCFB1E.45EE08A3-- From mary.ietf.barnes@gmail.com Mon Mar 5 19:13:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23E021E807C for ; Mon, 5 Mar 2012 19:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.59 X-Spam-Level: X-Spam-Status: No, score=-103.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2n9CLdfuIzM0 for ; Mon, 5 Mar 2012 19:13:16 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6986C21E8072 for ; Mon, 5 Mar 2012 19:13:16 -0800 (PST) Received: by vbbez10 with SMTP id ez10so4647135vbb.31 for ; Mon, 05 Mar 2012 19:13:16 -0800 (PST) Received-SPF: pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.91.193 as permitted sender) client-ip=10.52.91.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mary.ietf.barnes@gmail.com designates 10.52.91.193 as permitted sender) smtp.mail=mary.ietf.barnes@gmail.com; dkim=pass header.i=mary.ietf.barnes@gmail.com Received: from mr.google.com ([10.52.91.193]) by 10.52.91.193 with SMTP id cg1mr39674717vdb.21.1331003596044 (num_hops = 1); Mon, 05 Mar 2012 19:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=r+lxIAVvAhgIHubyC+dhyvREhPvaXfGKJordBrEfKfo=; b=ALx9f5nQSPLxwTwjmAi84EoYhSNwRCTNo7eLrlf5tDdK0babdxjynNnrfgormL29Ta NH7gEFRbwiLpve1sAQSPWLOKbJKt0gIfuKjov34/yoZd15NVuOGjsqHASL9GRrkH69wK xHEutTYW2vshGmIlp0B04nGx0ToHosRID3cToVYos2sAjMDj61bH+gChz8KcQiVr0sSt OcjUTgo4oYAnK3XOg5M/+zF2hU3R69YlM7e1HcmZpqw8502WGrf5pDjjEWqzw9mitJQv EAkhaAWCADGowyidhtPKKKhXQQec3VOpxg0HYI5i3jWAq9KnIIclS2Ti1yfNO/NWg+QU tBrA== MIME-Version: 1.0 Received: by 10.52.91.193 with SMTP id cg1mr33960891vdb.21.1331003595873; Mon, 05 Mar 2012 19:13:15 -0800 (PST) Received: by 10.52.111.136 with HTTP; Mon, 5 Mar 2012 19:13:15 -0800 (PST) Date: Mon, 5 Mar 2012 21:13:15 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec5015d2386db7c04ba8a6c08 Subject: [clue] No Design Team call on 3/6 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 03:13:17 -0000 --bcaec5015d2386db7c04ba8a6c08 Content-Type: text/plain; charset=ISO-8859-1 We will not have a call on Tuesday, March 6th. Mary. --bcaec5015d2386db7c04ba8a6c08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We will not have a call on Tuesday, March 6th.=A0

Mary.<= /div> --bcaec5015d2386db7c04ba8a6c08-- From mphmmr@gmail.com Mon Mar 5 20:58:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416AB21E8093 for ; Mon, 5 Mar 2012 20:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsOJMwcvGYdz for ; Mon, 5 Mar 2012 20:58:03 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEF6821E8091 for ; Mon, 5 Mar 2012 20:58:02 -0800 (PST) Received: by lagj5 with SMTP id j5so6777975lag.31 for ; Mon, 05 Mar 2012 20:58:01 -0800 (PST) Received-SPF: pass (google.com: domain of mphmmr@gmail.com designates 10.152.134.2 as permitted sender) client-ip=10.152.134.2; Authentication-Results: mr.google.com; spf=pass (google.com: domain of mphmmr@gmail.com designates 10.152.134.2 as permitted sender) smtp.mail=mphmmr@gmail.com; dkim=pass header.i=mphmmr@gmail.com Received: from mr.google.com ([10.152.134.2]) by 10.152.134.2 with SMTP id pg2mr13554252lab.3.1331009881809 (num_hops = 1); Mon, 05 Mar 2012 20:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BazLDT2DOWNwH+WAUq7fdamxdmpsDYZkICnb1gaMofs=; b=pwEPIGTiOqlg6MFshh4j4ItBCjuKDAkV+Ejr5sqknriDWYDHgOPPVgPz3vrDmasbrI PLareS1zZiviND9nMfCqXTfL78eMZlhoN9ggFFPIaM/BncN/j5+6Fi+s+1RGgBoFI6aj I7h55zCSLBSFt1r+wT5d5FM0SbHYXePyCnC7gczPoD/tYKk14QbU/n0NUbREWNQgouCu aVUOm32JH3ibEaUpFZ10Ijr+NPnGfAnvAHCVH7+z5OFdhd8hmgR3php0TI366XwE8z59 yHPOwT5bBWwe43tci7upPW5l+MjduvLqZidv1WmYKZ6gLWisEOs99uKQErajwN5eA3M0 XFhQ== MIME-Version: 1.0 Received: by 10.152.134.2 with SMTP id pg2mr11099733lab.3.1331009881733; Mon, 05 Mar 2012 20:58:01 -0800 (PST) Received: by 10.112.9.166 with HTTP; Mon, 5 Mar 2012 20:58:01 -0800 (PST) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> Date: Mon, 5 Mar 2012 23:58:01 -0500 Message-ID: From: Michael Hammer To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=f46d042ef7a931780e04ba8be365 Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 04:58:04 -0000 --f46d042ef7a931780e04ba8be365 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mark, Not sure if I am getting this properly. There seems to be only a couple concepts. Let me feed back to you in my terms and see if I am missing some key point. An atomic level (no lower subcomponents) media capture can be either a video capture (VC) or an audio capture (AC). A capture scene is an aggregation with structural meta-data that includes: - zero or more AC, or (logical meaning also "and") - zero or more VC, or - zero or more capture scenes, i.e. it aggregates iteratively. The capture scene can be constructed by either the media provider or the media consumer. That last point seems to be implied by "provider arranges" and "consumer can choose" but would be good to verify. I would think that what the sender does prior or what the receiver does subsequent to receipt might be secondary. Miss anything? Mike On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark wrote: > At the interim meeting, there was some support for combining the concepts > of =93capture scene=94 and =93capture set=94 into a single concept. So h= ere is a > rough proposal for doing that, essentially using the term =93capture scen= e=94 > to replace the previous term =93capture set=94, and eliminating the origi= nal > separate capture scene concept.**** > > ** ** > > Definitions:**** > > ** ** > > *Capture Scene: a structure representing the scene that is captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. **** > > ** ** > > *Capture Scene Entry: a list of media captures of the same media type tha= t > together form one way to represent the capture scene.**** > > ** ** > > Text for section 6.2 Capture Scene (was 6.2 Capture Set):**** > > ** ** > > A capture scene represents, for example, the video image of a group of > people seated next to each other, along with the sound of their voices, > which could be represented by some number of VCs and ACs in the capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives.**** > > ** ** > > A media provider arranges media captures in a capture scene to help the > media consumer choose which captures it wants. The capture scene entries > in a capture scene are different alternatives the provider is suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each media ty= pe > (e.g. audio and video), or it can pick and choose media captures regardle= ss > of how the provider arranges them in capture scene entries.**** > > ** ** > > A capture scene may include more than one type of media. For example, a > capture scene can include several capture scene entries for video capture= s, > and several capture scene entries for audio captures. **** > > ** ** > > (This text would be worked into section 6.2, not replace it completely. > Other things in section 6.2 and elsewhere would need to be edited to be > consistent with the new terminology in this proposal)**** > > ** ** > > Regards,**** > > Mark**** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --f46d042ef7a931780e04ba8be365 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mark,

Not sure if I am getting this properly. =A0There s= eems to be only a couple concepts.
Let me feed back to you in my = terms and see if I am missing some key point.

An a= tomic level (no lower subcomponents) media capture can be either a video ca= pture (VC) or an audio capture (AC).
A capture scene is an aggregation with structural meta-data that inclu= des:
- zero or more AC, or (logical meaning also "and")=
- zero or more VC, or
- zero or more capture scenes, i= .e. it aggregates iteratively.
The capture scene can be constructed by either the media provider or t= he media consumer.

That last point seems to be imp= lied by "provider arranges" and "consumer can choose" b= ut would be good to verify.
I would think that what the sender does prior or what the receiver doe= s subsequent to receipt might be secondary.

Miss a= nything?
Mike



On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark <Mark.Duckworth@p= olycom.com> wrote:

At the interim meeting, there was some support for combining the concep= ts of =93capture scene=94 and =93capture set=94 into a single concept.=A0 S= o here is a rough proposal for doing that, essentially using the term =93ca= pture scene=94 to replace the previous term =93capture set=94, and eliminat= ing the original separate capture scene concept.

=A0

Definiti= ons:

=A0

*Capture Scene: a structure representing the scene that is c= aptured by a collection of capture devices.=A0 A capture scene includes one= or more capture scene entries, with each entry including one or more media= captures.=A0

=A0

*Capture= Scene Entry: a list of media captures of the same media type that together= form one way to represent the capture scene.

=A0

Text for section 6.2 Capture Sc= ene (was 6.2 Capture Set):

= =A0

A capture scene represents, for exampl= e, the video image of a group of people seated next to each other, along wi= th the sound of their voices, which could be represented by some number of = VCs and ACs in the capture scene entries. A middle box may also express cap= ture scenes that it constructs from media streams it receives.

=A0

A media = provider arranges media captures in a capture scene to help the media consu= mer choose which captures it wants.=A0 The capture scene entries in a captu= re scene are different alternatives the provider is suggesting for represen= ting the capture scene.=A0 The media consumer can choose to receive all med= ia captures from one capture scene entry for each media type (e.g. audio an= d video), or it can pick and choose media captures regardless of how the pr= ovider arranges them in capture scene entries.

=A0

A captur= e scene may include more than one type of media.=A0 For example, a capture = scene can include several capture scene entries for video captures, and sev= eral capture scene entries for audio captures.=A0

=A0

(This te= xt would be worked into section 6.2, not replace it completely.=A0 Other th= ings in section 6.2 and elsewhere would need to be edited to be consistent = with the new terminology in this proposal)

=A0

Regards,=

Mark

=
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--f46d042ef7a931780e04ba8be365-- From ron.even.tlv@gmail.com Mon Mar 5 23:41:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2DF21E805A for ; Mon, 5 Mar 2012 23:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f-5Lyu17ECT for ; Mon, 5 Mar 2012 23:41:39 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9487621E8017 for ; Mon, 5 Mar 2012 23:41:38 -0800 (PST) Received: by eaaq11 with SMTP id q11so1668766eaa.31 for ; Mon, 05 Mar 2012 23:41:37 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.205.67 as permitted sender) client-ip=10.14.205.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.205.67 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.205.67]) by 10.14.205.67 with SMTP id i43mr874933eeo.33.1331019697850 (num_hops = 1); Mon, 05 Mar 2012 23:41:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=BIHA79N7veBtHeKxNXeb4jnJr7bJJKy7ErDicsPdNZU=; b=DcbV7WzDEYiQEnhnU2ZphArLPU4DDETJD3uQUH93cNYbIjjb6eFiET79rS3JDJurnD brMysAvVJJfzEntlOfM7QDBkxP6dR1v24CRssPYbJgbZdNkVEVrgOqgvP4fPjbSGKE/8 8t7Yclx5fB7k8goNrhP5fjXs6t8xySVpjrtO2vC0qdoojJlNveLpyfFYmwGLwh8m0L+J i6dtenmfdl4GXMx5hWp2BLT1/1rq972JOVIQhYpQ+Gyo/SxNYPHscNFCQFIhW/8/BK0a 028t/qRd+oOBeZLJBUH4JmHj3lJGteu4mKFOkW1DZ3t5tJadsxgSLKrZlz8zk07Cf5Wl E7SA== Received: by 10.14.205.67 with SMTP id i43mr665623eeo.33.1331019697741; Mon, 05 Mar 2012 23:41:37 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id d54sm25398906eei.9.2012.03.05.23.41.33 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 05 Mar 2012 23:41:36 -0800 (PST) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> <4f550a6f.cb620e0a.3e2d.488d@mx.google.com> <92DF9533227FC14F946C7321074B8C9EFC3928@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9EFC3928@XMB-AMS-214.cisco.com> Date: Tue, 6 Mar 2012 09:40:28 +0200 Message-ID: <4f55bfb0.ce7f0e0a.645e.3c53@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B2_01CCFB7D.2C1243A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz6/MLPU1dr3btARqORYI12DkPslgAAx7cAAAc8xbAAEhxwAA== Content-Language: en-us Subject: Re: [clue] Ticket #7 composed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:41:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06B2_01CCFB7D.2C1243A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Espen, I am not arguing that we can decide that CLUE will not specify the composition or switched policy. If this is what we will have than the text should be clear about it. This will mean that CLUE does not provide a way for the provider to specify what is composed and mixed and thus the consumer cannot use CLUE to select a specific mix or switch. Currently this can be available using other menas like XCON protocol. In your email "The example use case we used where a triple camera system that can do, I only list the single capture alternatives. a) A manually selected alternative, left, center or right b) A switched alternative; based on voice activity c) A composited alternative; by media source choosing. " Is not correct if switched and composed are Booleans. It should be " The example use case we used where a triple camera system that can do, I only list the single capture alternatives. a) A manually selected alternative, left, center or right b) A switched alternative; that may based on voice activity or any other switching policy base on the media source decision c) A composited alternative; by media source choosing. I am OK with the specification in section 6.1.1 of the framework but prefer adding text to the composed and switched attribute that mechanism based on draft-ietf-xcon-event-package can be used to learn the content of the stream. Also in section 11.1 based in the definition of composed and switched the following is not correct: " o VC3- (the loudest panel stream), encoding group=EG1, purpose=main;auto-switched:yes o VC4- (the loudest panel stream with PiPs), encoding group=EG1, purpose=main; composed=true; auto-switched:yes " In order not to set some assumptions for the readers who did not follow the discussion it should be "o VC3- (may be the loudest panel stream based on producer policy), encoding group=EG1, purpose=main;auto-switched:yes o VC4- (may be the loudest panel stream with PiPs based on producer policy), encoding group=EG1, purpose=main; composed=true; auto-switched:yes " Note that in section 11.1 you use auto-switch as the attribute name instead of switched as specified in section 6.1.1, I assume it is a typo. Roni Even From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Tuesday, March 06, 2012 12:20 AM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Ticket #7 composed attribute During the discussions we did not find any clear use case that must be handled in CLUE that involves more than announcing a single composited alternative. Even if there are use cases where that could be possible we discussed them as outside out the scope of version 1 of CLUE. One example we decided to keep out was the video layout as specified in the XCON data model [1]. As presented multiple video-layout alternative can be listed as a single multi value attribute with all options listed and still keep the number of captures the same. The example use case we used where a triple camera system that can do, I only list the single capture alternatives. d) A manually selected alternative, left, center or right e) A switched alternative; based on voice activity f) A composited alternative; by media source choosing. In this case its sufficient to use a flag to separate alternative b and c, and we concluded that a basic flag was sufficient. Vendors are free to extend on the basic model with more details if they think that is needed. -Espen [1] http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-32 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 5. mars 2012 19:47 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Ticket #7 composed attribute Hi, I did not support this and this was added to the action item when I was not present. The discussion in the meeting was about allowing the provider to offer more than one composed option that will allow the consumer to select from. There was no agreement during the session as far as I can see from the notes and the summary does not reflect the discussion. BTW: These are rough notes and there is no meeting summary yet from the WG chairs Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 05, 2012 8:26 PM To: clue@ietf.org Subject: [clue] Ticket #7 composed attribute >From the interim meeting minutes: "3.2.6 Is "Composed" a Boolean, or a data structure? Based on previous issue - Boolean is as far as CLUE should go." My recollection is that the people in the meeting generally agreed on this. So it seems to me this is the resolution of ticket #7. Is that correct? Mark _____ ------=_NextPart_000_06B2_01CCFB7D.2C1243A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Espen,

I am not arguing that we = can decide that CLUE will not specify the composition or switched = policy. If this is what we will have than the text should be clear about = it.

This will mean that CLUE does not provide a way = for the provider to specify what is composed and mixed and thus the = consumer cannot use CLUE to select a specific mix or switch. Currently = this can be available using other menas like XCON = protocol.

 

=

In your email

 

"The = example use case we used where a triple camera system that can do, I = only list the single capture alternatives.

a)      = A manually selected alternative, left, center or = right

b)      = A switched alternative; based on voice activity =

c)       = A composited alternative; by media source = choosing. "

 

 

Is not correct if switched and composed are = Booleans. It should be

"

The example = use case we used where a triple camera system that can do, I only list = the single capture alternatives.

a)      = A manually selected alternative, left, center or = right

b)      = A switched alternative; that may based on voice = activity  or any other switching policy base on the media source = decision

c)       = A composited alternative; by media source = choosing.

 

 

I am OK = with the specification in section 6.1.1 of the framework but prefer = adding text to the composed and switched attribute that mechanism based = on draft-ietf-xcon-event-package can be used to learn the content of the = stream.

 

Also in = section 11.1 based in the definition of composed and switched the = following is not correct:

 

" o  VC3- (the loudest panel = stream), encoding group=3DEG1,

      = purpose=3Dmain;auto-switched:yes

 

   o  VC4- (the = loudest panel stream with PiPs), encoding = group=3DEG1,

      = purpose=3Dmain; composed=3Dtrue; = auto-switched:yes

"

 

In order not to set some = assumptions for the readers who did not follow the discussion it should = be

 

"o  VC3- (may be the loudest panel stream based on = producer policy), encoding group=3DEG1,

      = purpose=3Dmain;auto-switched:yes

 

   o  VC4- (may be = the loudest panel stream with PiPs based on producer policy), encoding = group=3DEG1,

      = purpose=3Dmain; composed=3Dtrue; = auto-switched:yes

"

 

 

Note that in section = 11.1 you use auto-switch as the attribute name instead of switched as = specified in section 6.1.1, I assume it is a = typo.

 

 

Roni = Even

 

 

 

 

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: = Tuesday, March 06, 2012 12:20 AM
To: Roni Even; Duckworth, = Mark; clue@ietf.org
Subject: RE: [clue] Ticket #7 composed = attribute

 

 

During the = discussions we did not find any clear use case that must be handled in = CLUE that involves more than announcing a single composited alternative. = Even if there are use cases where that could be possible we discussed = them as outside out the scope of version 1 of CLUE. =

 

One example = we decided to keep out was the video layout as specified in the XCON = data model [1]. As presented multiple video-layout alternative can be = listed as a single multi value attribute with all options listed and = still keep the number of captures the same.

 

The example = use case we used where a triple camera system that can do, I only list = the single capture alternatives.

d)      = A manually selected alternative, left, center or = right

e)      = A switched alternative; based on voice activity =

f)       = A composited alternative; by media source = choosing.

 

In this = case its sufficient to use a flag to separate alternative b and c, and = we concluded that a basic flag was sufficient. Vendors are free to = extend on the basic model with more details if they think that is = needed.

 

-Espen =

[1] = http://tools.ietf.org/html/draft-ietf-xcon-common-data-model-32

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Roni Even
Sent: 5. mars 2012 = 19:47
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: = [clue] Ticket #7 composed attribute

 

Hi,

I did not support this = and this was added to the action item when I was not = present.

The discussion in the meeting was about allowing = the provider to offer more than one composed option that will allow the = consumer to select from. There was no agreement during the session as = far as I can see from the notes and the summary does not reflect the = discussion.

BTW: These are rough notes and there is no = meeting summary yet from the WG chairs

Roni = Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Monday, March 05, = 2012 8:26 PM
To: clue@ietf.org
Subject: = [clue] Ticket #7 composed attribute

 

From the = interim meeting minutes:

“3.2.6 Is = “Composed” a Boolean, or a data structure? Based on previous = issue – Boolean is as far as CLUE should = go.”

 

My recollection is that the people in the = meeting generally agreed on this.  So it seems to me this is the = resolution of ticket #7.  Is that correct?

 

Mark

 

------=_NextPart_000_06B2_01CCFB7D.2C1243A0-- From ron.even.tlv@gmail.com Tue Mar 6 00:24:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DFD21E80B5 for ; Tue, 6 Mar 2012 00:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1jCbM2vdCvi for ; Tue, 6 Mar 2012 00:24:29 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9E321E808C for ; Tue, 6 Mar 2012 00:24:28 -0800 (PST) Received: by eeke51 with SMTP id e51so1747750eek.31 for ; Tue, 06 Mar 2012 00:24:27 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.29.1 as permitted sender) client-ip=10.14.29.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.29.1 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.29.1]) by 10.14.29.1 with SMTP id h1mr13108061eea.25.1331022267793 (num_hops = 1); Tue, 06 Mar 2012 00:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=X7Sh4pHK1cgHCJCVjrLLZR8nZ2OZm6HhA8H5vLpqZqY=; b=Cil/BedYO+qfxWfuQ7gVBG7JFh/wSzCiDqoS4IMS6VaVFIKwIPIZJz15WUdQwyoW25 QL0XBhgfm0h0F2ylFwJui7MfN1732CUlvff6n/qnUvHpw+miyFBvNwrY6qywAKwvlrWB +76arH9sOojbt1nTIoNDIVNi3NB+5R9PJiJbYMQaRI2Lc5ajWysklpbrGsWWo8hez5p2 g+8XIo//hz/mQD47GcACI+B7P8yAz0zGeVyvIhhgChhEI3jNlcaCHyZguhc4+Mjty9Yo r/p7yl88blLguFxn2tI0VQrICEFLCb40Wk/wCBUK3c203xLzIQkq3Wn9++BO8EwJzpxh 60CQ== Received: by 10.14.29.1 with SMTP id h1mr9984744eea.25.1331022267702; Tue, 06 Mar 2012 00:24:27 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id u9sm71755103eem.11.2012.03.06.00.24.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Mar 2012 00:24:26 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> Date: Tue, 6 Mar 2012 10:23:20 +0200 Message-ID: <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06BD_01CCFB83.28BD3D80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz7BEjU/dWlSEAnQuC91hY5WY2g+gAbaOOA Content-Language: en-us Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:24:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06BD_01CCFB83.28BD3D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mark, I do not care how we call it. What I am missing is the top level. Does a provider advertise one capture scene composed of multiple capture scene entries. My understanding so far was that there can be more than one if we substitute set with scene. Can there be more than one capture scene in the advertisement in which case how do you differentiate between them, is there a scene identifier and how does the consumer know what is the scene. Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 05, 2012 9:16 PM To: clue@ietf.org Subject: [clue] Proposal to combine capture scene and capture set At the interim meeting, there was some support for combining the concepts of "capture scene" and "capture set" into a single concept. So here is a rough proposal for doing that, essentially using the term "capture scene" to replace the previous term "capture set", and eliminating the original separate capture scene concept. Definitions: *Capture Scene: a structure representing the scene that is captured by a collection of capture devices. A capture scene includes one or more capture scene entries, with each entry including one or more media captures. *Capture Scene Entry: a list of media captures of the same media type that together form one way to represent the capture scene. Text for section 6.2 Capture Scene (was 6.2 Capture Set): A capture scene represents, for example, the video image of a group of people seated next to each other, along with the sound of their voices, which could be represented by some number of VCs and ACs in the capture scene entries. A middle box may also express capture scenes that it constructs from media streams it receives. A media provider arranges media captures in a capture scene to help the media consumer choose which captures it wants. The capture scene entries in a capture scene are different alternatives the provider is suggesting for representing the capture scene. The media consumer can choose to receive all media captures from one capture scene entry for each media type (e.g. audio and video), or it can pick and choose media captures regardless of how the provider arranges them in capture scene entries. A capture scene may include more than one type of media. For example, a capture scene can include several capture scene entries for video captures, and several capture scene entries for audio captures. (This text would be worked into section 6.2, not replace it completely. Other things in section 6.2 and elsewhere would need to be edited to be consistent with the new terminology in this proposal) Regards, Mark ------=_NextPart_000_06BD_01CCFB83.28BD3D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark,

I do not care how we = call it. What I am missing is the top level.

Does a provider = advertise one capture scene composed of multiple capture scene entries. = My understanding so far was that there can be  more than one if we = substitute set with scene.

Can there be more than = one capture scene in the advertisement in which case how do you = differentiate between them, is there a scene identifier and how does the = consumer know what is the scene.

Roni = Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Monday, March 05, 2012 9:16 = PM
To: clue@ietf.org
Subject: [clue] Proposal to = combine capture scene and capture = set

 

At the = interim meeting, there was some support for combining the concepts of = “capture scene” and “capture set” into a single = concept.  So here is a rough proposal for doing that, essentially = using the term “capture scene” to replace the previous term = “capture set”, and eliminating the original separate capture = scene concept.

 

Definitions:

 

*Capture = Scene: a structure representing the scene that is captured by a = collection of capture devices.  A capture scene includes one or = more capture scene entries, with each entry including one or more media = captures. 

 

*Capture = Scene Entry: a list of media captures of the same media type that = together form one way to represent the capture scene.

 

Text for = section 6.2 Capture Scene (was 6.2 Capture Set):

 

A capture = scene represents, for example, the video image of a group of people = seated next to each other, along with the sound of their voices, which = could be represented by some number of VCs and ACs in the capture scene = entries. A middle box may also express capture scenes that it constructs = from media streams it receives.

 

A media = provider arranges media captures in a capture scene to help the media = consumer choose which captures it wants.  The capture scene entries = in a capture scene are different alternatives the provider is suggesting = for representing the capture scene.  The media consumer can choose = to receive all media captures from one capture scene entry for each = media type (e.g. audio and video), or it can pick and choose media = captures regardless of how the provider arranges them in capture scene = entries.

 

A capture scene may include more than one type of = media.  For example, a capture scene can include several capture = scene entries for video captures, and several capture scene entries for = audio captures. 

 

(This text = would be worked into section 6.2, not replace it completely.  Other = things in section 6.2 and elsewhere would need to be edited to be = consistent with the new terminology in this proposal)

 

Regards,

Mark

------=_NextPart_000_06BD_01CCFB83.28BD3D80-- From ron.even.tlv@gmail.com Tue Mar 6 00:29:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1EC21F8616 for ; Tue, 6 Mar 2012 00:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xYiXhAkpdOu for ; Tue, 6 Mar 2012 00:29:34 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD03121F8611 for ; Tue, 6 Mar 2012 00:29:33 -0800 (PST) Received: by eaaq11 with SMTP id q11so1682110eaa.31 for ; Tue, 06 Mar 2012 00:29:32 -0800 (PST) Received-SPF: pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.183.136 as permitted sender) client-ip=10.14.183.136; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ron.even.tlv@gmail.com designates 10.14.183.136 as permitted sender) smtp.mail=ron.even.tlv@gmail.com; dkim=pass header.i=ron.even.tlv@gmail.com Received: from mr.google.com ([10.14.183.136]) by 10.14.183.136 with SMTP id q8mr13090780eem.60.1331022572929 (num_hops = 1); Tue, 06 Mar 2012 00:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=V+d9oq4w1Wc2/q8xkoDCZjJUuUHaJ2NB3CLC+Y08h4A=; b=aWMTJSmSw3SUNvZF4fY7rG4+JatoAAmJhxsV/9tj9IeTwzSEXTpf/EHS0vz3jckCiU 7ow2J0EAsDLu6vEKQi89KQsQEZxYG9ytX9ETJsPgUC9R8eOQPQHayu7XAoN/IEanYZ2D VnEPuODj4MVfoxlHuWVFSedBOyuDISYyefiaIecHaT4+Qc8toSd76aG0DSRYuI6ktQq/ Yzha3s26YNOps2HWp4l5uxw1V32I+1mQ57Qer/N9PXC/kIgEP9+Wj8zum2yN0eYVQDjJ T83C5IEe6WHF6zpKSDkt8bzljR+Lcs7byZpebp8YmInA8Me0fc2TGSyGFBKA1Y0fWWaM 16Fg== Received: by 10.14.183.136 with SMTP id q8mr9934576eem.60.1331022572879; Tue, 06 Mar 2012 00:29:32 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id n55sm31813985eef.6.2012.03.06.00.29.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Mar 2012 00:29:32 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C805B@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C805B@CRPMBOXPRD01.polycom.com> Date: Tue, 6 Mar 2012 10:28:25 +0200 Message-ID: <4f55caec.cf5e0e0a.5211.ffffd6f2@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06C2_01CCFB83.DE9E0FD0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz7CVVv4KEEqhZGQBGw2/oY+gJ9ZQAaTL+Q Content-Language: en-us Subject: Re: [clue] switch-policy attribute proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:29:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06C2_01CCFB83.DE9E0FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark, I am OK with this. I assume this applies to the multipoint case, maybe add a reference to the relevant use case in the use case draft. I am not sure about the attribute name since there is no intent to make it the general switch case for example "voice activated", "round robin" Maybe change the attribute name to TP-switch-policy and emphasis the purpose of the attribute. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 05, 2012 9:51 PM To: clue@ietf.org Subject: [clue] switch-policy attribute proposal At the interim meeting I think people generally agreed the clue framework should include a way for a provider to advertise site-switching and segment-switching policies, and for the consumer to request one or the other. Here is a rough proposal. Add a new "switch-policy" attribute for a capture scene entry (or capture set entry, using the framework-03 terminology) (note the attribute is for a capture scene entry not a media capture). Switch-policy: {site-switch, segment-switch} An attribute with enumerated values which identifies the policy the provider uses for how to switch the various media captures within the capture scene entry. A value of 'site-switch' means all the media captures within the capture scene entry typically switch together, with the provider attempting to include all the media captures from the same site together. A value of 'segment-switch' means the media captures in the entry switch independently of each other, so at any point in time the media captures could be originally sourced from different sites. In a provider advertisement, the provider can include multiple values for the switch-policy attribute. The provider is saying it can provide any one of those switch-policies it advertises. When a consumer configures the provider, the consumer includes this attribute with only the single value for switch-policy that it wants to receive. Regards, Mark ------=_NextPart_000_06C2_01CCFB83.DE9E0FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

I am OK with this. I = assume this applies to the multipoint case, maybe add a reference to the = relevant use case in the use case draft.

 

I am not sure about the = attribute name since there is no intent to make it the general switch = case for example "voice activated", "round = robin"

Maybe change the attribute name to = TP-switch-policy and emphasis the purpose of the = attribute.

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Monday, March 05, 2012 9:51 = PM
To: clue@ietf.org
Subject: [clue] switch-policy = attribute proposal

 

At the = interim meeting I think people generally agreed the clue framework = should include a way for a provider to advertise site-switching and = segment-switching policies, and for the consumer to request one or the = other.  Here is a rough proposal.

 

Add a new = “switch-policy” attribute for a capture scene entry (or = capture set entry, using the framework-03 terminology) (note the = attribute is for a capture scene entry not a media = capture).

 

Switch-policy: {site-switch, = segment-switch}

An attribute with = enumerated values which identifies the policy the provider uses for how = to switch the various media captures within the capture scene = entry.

A value of = ‘site-switch’ means all the media captures within the = capture scene entry typically switch together, with the provider = attempting to include all the media captures from the same site = together.

A value of = ‘segment-switch’ means the media captures in the entry = switch independently of each other, so at any point in time the media = captures could be originally sourced from different = sites.

 

In a provider advertisement, the provider can include = multiple values for the switch-policy attribute.  The provider is = saying it can provide any one of those switch-policies it = advertises.  When a consumer configures the provider, the consumer = includes this attribute with only the single value for switch-policy = that it wants to receive.

 

Regards,

Mark

------=_NextPart_000_06C2_01CCFB83.DE9E0FD0-- From bbaldino@cisco.com Tue Mar 6 02:11:06 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4186C21F8701 for ; Tue, 6 Mar 2012 02:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR2EJLhiu4-a for ; Tue, 6 Mar 2012 02:11:00 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA1521F8647 for ; Tue, 6 Mar 2012 02:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bbaldino@cisco.com; l=12152; q=dns/txt; s=iport; t=1331028660; x=1332238260; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=mItI0tINNaimPFmkWZjjsZxdKvUndu+TqU4dS2EY3LI=; b=BNkShisG4Q9m6bkNIGZQmiUnFr+ouiR3L7ymsfIBCmwEmoz+zRSJJwib yyQpe5gz119uzp90LqEPcHIjfAVN0EyS7OIsnV4LAWVoLm7g/qZDHrguq 0vUA8Sv84ZqU7sMmUkKFSCQJ1XIbThkFoo8KbSK/9toi+6TzaAoFJKSaa s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHThVU+rRDoI/2dsb2JhbABDgkWyM4EHgX0BAQEEEgEJEQNZAgEIDgMEAQELBhcBBgFFCQgBAQQBEggah2QBmjoBnxiPe2MEiFCdBIME X-IronPort-AV: E=Sophos;i="4.73,539,1325462400"; d="scan'208,217";a="32165445" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 06 Mar 2012 10:11:00 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q26AAx57030137; Tue, 6 Mar 2012 10:10:59 GMT Received: from xmb-sjc-233.amer.cisco.com ([128.107.191.88]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 02:10:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFB81.6D7037B9" Date: Tue, 6 Mar 2012 02:10:58 -0800 Message-ID: In-Reply-To: <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Proposal to combine capture scene and capture set Thread-Index: Acz7BEjU/dWlSEAnQuC91hY5WY2g+gAbaOOAAAPVPpA= References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> From: "Brian Baldino (bbaldino)" To: "Roni Even" , "Duckworth, Mark" , X-OriginalArrivalTime: 06 Mar 2012 10:10:59.0689 (UTC) FILETIME=[6DB5DD90:01CCFB81] Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:11:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB81.6D7037B9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hey Roni, I think this is just a vocabulary change-multiple capture scenes are still allowed. The idea was that the 'purpose' attribute of the capture scene would be used to differentiate them. =20 -Brian=20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, March 06, 2012 12:23 AM To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set =20 Hi Mark, I do not care how we call it. What I am missing is the top level. Does a provider advertise one capture scene composed of multiple capture scene entries. My understanding so far was that there can be more than one if we substitute set with scene. Can there be more than one capture scene in the advertisement in which case how do you differentiate between them, is there a scene identifier and how does the consumer know what is the scene. Roni Even =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 05, 2012 9:16 PM To: clue@ietf.org Subject: [clue] Proposal to combine capture scene and capture set =20 At the interim meeting, there was some support for combining the concepts of "capture scene" and "capture set" into a single concept. So here is a rough proposal for doing that, essentially using the term "capture scene" to replace the previous term "capture set", and eliminating the original separate capture scene concept. =20 Definitions: =20 *Capture Scene: a structure representing the scene that is captured by a collection of capture devices. A capture scene includes one or more capture scene entries, with each entry including one or more media captures. =20 =20 *Capture Scene Entry: a list of media captures of the same media type that together form one way to represent the capture scene. =20 Text for section 6.2 Capture Scene (was 6.2 Capture Set): =20 A capture scene represents, for example, the video image of a group of people seated next to each other, along with the sound of their voices, which could be represented by some number of VCs and ACs in the capture scene entries. A middle box may also express capture scenes that it constructs from media streams it receives. =20 A media provider arranges media captures in a capture scene to help the media consumer choose which captures it wants. The capture scene entries in a capture scene are different alternatives the provider is suggesting for representing the capture scene. The media consumer can choose to receive all media captures from one capture scene entry for each media type (e.g. audio and video), or it can pick and choose media captures regardless of how the provider arranges them in capture scene entries. =20 A capture scene may include more than one type of media. For example, a capture scene can include several capture scene entries for video captures, and several capture scene entries for audio captures. =20 =20 (This text would be worked into section 6.2, not replace it completely. Other things in section 6.2 and elsewhere would need to be edited to be consistent with the new terminology in this proposal) =20 Regards, Mark ------_=_NextPart_001_01CCFB81.6D7037B9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hey = Roni,

I = think this is just a vocabulary change—multiple capture scenes are = still allowed.  The idea was that the ‘purpose’ = attribute of the capture scene would be used to differentiate = them.

 

-Brian

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Tuesday, March 06, 2012 12:23 = AM
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: = [clue] Proposal to combine capture scene and capture = set

 

Hi Mark,

I do not care how we = call it. What I am missing is the top level.

Does a provider = advertise one capture scene composed of multiple capture scene entries. = My understanding so far was that there can be  more than one if we = substitute set with scene.

Can there be more than = one capture scene in the advertisement in which case how do you = differentiate between them, is there a scene identifier and how does the = consumer know what is the scene.

Roni = Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.= org] On Behalf Of Duckworth, Mark
Sent: Monday, = March 05, 2012 9:16 PM
To: clue@ietf.org
Subject: = [clue] Proposal to combine capture scene and capture = set

 

At the = interim meeting, there was some support for combining the concepts of = “capture scene” and “capture set” into a single = concept.  So here is a rough proposal for doing that, essentially = using the term “capture scene” to replace the previous term = “capture set”, and eliminating the original separate capture = scene concept.

 

Definitions:

 

*Capture = Scene: a structure representing the scene that is captured by a = collection of capture devices.  A capture scene includes one or = more capture scene entries, with each entry including one or more media = captures. 

 

*Capture = Scene Entry: a list of media captures of the same media type that = together form one way to represent the capture scene.

 

Text for = section 6.2 Capture Scene (was 6.2 Capture Set):

 

A capture = scene represents, for example, the video image of a group of people = seated next to each other, along with the sound of their voices, which = could be represented by some number of VCs and ACs in the capture scene = entries. A middle box may also express capture scenes that it constructs = from media streams it receives.

 

A media = provider arranges media captures in a capture scene to help the media = consumer choose which captures it wants.  The capture scene entries = in a capture scene are different alternatives the provider is suggesting = for representing the capture scene.  The media consumer can choose = to receive all media captures from one capture scene entry for each = media type (e.g. audio and video), or it can pick and choose media = captures regardless of how the provider arranges them in capture scene = entries.

 

A capture scene may include more than one type of = media.  For example, a capture scene can include several capture = scene entries for video captures, and several capture scene entries for = audio captures. 

 

(This text = would be worked into section 6.2, not replace it completely.  Other = things in section 6.2 and elsewhere would need to be edited to be = consistent with the new terminology in this proposal)

 

Regards,

Mark

------_=_NextPart_001_01CCFB81.6D7037B9-- From johaniel@cisco.com Tue Mar 6 05:43:41 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E86021F878B for ; Tue, 6 Mar 2012 05:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQQF-J9BJ2H3 for ; Tue, 6 Mar 2012 05:43:38 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 58E7721F87EC for ; Tue, 6 Mar 2012 05:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johaniel@cisco.com; l=25301; q=dns/txt; s=iport; t=1331041417; x=1332251017; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=cyloUQEYQxTHQmJsFwQcHrFlRKWwlS9afB5ZQIKiW+E=; b=AIFnCqJIrK0qOcOPlqn6sWyfz/1+FD7NNr2VJ6g7xGKsGDvZHfZvTCfI zwIg5J3jAVgqxcuy+sOeGQ14OtLcAen4rL1pGHVzsz+BERBVQdmbIwnDP rAticnMkjqXSLrAXUatTg6ugbhWqvIpu91sHAP6pQMUfv6yFLkGEbiz4f 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOITVk+Q/khL/2dsb2JhbABDgkWyI4EHgX0BAQEEEgEJEQNCFwIBCA4DBAEBCwYQBwEGASAlCQgBAQQBEggah2WaKQGfDYk7hkBjBKBfhHaCZA X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208,217";a="67792784" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 06 Mar 2012 13:43:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q26DhYhV009665; Tue, 6 Mar 2012 13:43:34 GMT Received: from xmb-ams-206.cisco.com ([144.254.75.17]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 14:43:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFB9F.1FCC5BCE" Date: Tue, 6 Mar 2012 14:43:33 +0100 Message-ID: <05DD269BD82AA549BC4B2619BBAC466AEC5EFA@XMB-AMS-206.cisco.com> In-Reply-To: <4f512513.0f7f0e0a.6652.52d6@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgABIgOgAAFYB3AAU9pBgAAIs9QwALx44sA= References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com><4f4eb007.85600e0a.1d16.74b8@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> <05DD269BD82AA549BC4B2619BBAC466AEC5B92@XMB-AMS-206.cisco.com> <4f512513.0f7f0e0a.6652.52d6@mx.google.com> From: "Johan Ludvig Nielsen (johaniel)" To: "Roni Even" , "Duckworth, Mark" , X-OriginalArrivalTime: 06 Mar 2012 13:43:34.0281 (UTC) FILETIME=[200A2790:01CCFB9F] Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:43:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB9F.1FCC5BCE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, good point. Johan =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: 2. mars 2012 20:52 To: Johan Ludvig Nielsen (johaniel); 'Duckworth, Mark'; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets =20 Hi, The simultaneous discussion is about describing physical constrains while audio and video connection is application connection. I am not sure if the audio video should be part of the physical constrains. Also note that the SDP grouping already provides for it, but if you want it in CLUE it should be s different attribute. Roni Even =20 From: Johan Ludvig Nielsen (johaniel) [mailto:johaniel@cisco.com]=20 Sent: Friday, March 02, 2012 5:43 PM To: Duckworth, Mark; Roni Even; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets =20 Hi =20 I think it would be useful to include audio and connection between audio and video in this discussion.=20 =20 Can the simultaneous or mutually-exclusive sets be used to specify which audio captures can be used with which video captures, and which cannot? =20 This could solve the case in 11.1 where the connection through the capture area is insufficient for some captures, as I have pointed out in an earlier post on the spatial relationships. =20 Regards Johan =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 1. mars 2012 00:48 To: Roni Even; clue@ietf.org Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets =20 Hi, For this example it would be a little simpler like this: VC1 - mutually-exclusive=3D{VC5} VC3 - mutually-exclusive=3D{VC5} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1,VC3,VC4} =20 The point for scalability was to simplify a case like this: VC1 - mutually-exclusive=3D{VC2} VC2 - mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC4} VC4 - mutually-exclusive=3D{VC3} VC5 - mutually-exclusive=3D{VC6} VC6 - mutually-exclusive=3D{VC5} =20 In simultaneous sets it would have been: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 Adding another mutually exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs each. =20 I agree the framework should clarify that capture set entries are the provider's suggestion to the consumer about which media captures would be most useful to receive together. =20 I agree the framework should clarify that the consumer can choose just part of a capture set entry. =20 The consumer can also pick and choose media captures from different capture set entries, and for this case the mutually exclusive information becomes important. =20 Mark =20 =20 =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Wednesday, February 29, 2012 6:08 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simutaneous sets =20 Hi, I do not think that changes anything since this is the complement of the simultaneous set and will be less condensed. For example taking the example from the framework in section 11.1 =20 The physical simultaneity information is: =20 {VC0, VC1, VC2, VC3, VC4, VC6} =20 {VC0, VC2, VC5, VC6} =20 Your proposal will require VC1 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC3} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC4} And the result is the same since it can be translated to the current description. =20 My proposal was to clarify in the framework that the capture set entries are the preferred mode as proposed by the provider. Also to say that a consumer can select part of a capture set entry or simultaneous set. =20 Roni =20 =20 =20 =20 =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets =20 This is a proposal from all the framework authors. Please review. =20 We propose removing the concept of "simultaneous sets" and replacing it with a new media capture attribute called "mutually exclusive". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. This is in response to concerns discussed at the interim meeting about scalability of simultaneous sets, and confusion between simultaneous sets and capture set entries. =20 New Media Capture attribute: =20 Mutually-exclusive: {list of MCs that cannot be used at same time as this MC} =20 Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. =20 The provider specifies this with the following video capture attribute values: VC1 - mutually-exclusive=3D{VC3} VC3 - mutually-exclusive=3D{VC1} =20 A provider must advertise mutually exclusive attributes that allow all the media captures in a capture set entry to be used at the same time. =20 Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather than the simultaneous sets. =20 Mark =20 ------_=_NextPart_001_01CCFB9F.1FCC5BCE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, good point.

Johan

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 2. mars 2012 = 20:52
To: Johan Ludvig Nielsen (johaniel); 'Duckworth, Mark'; = clue@ietf.org
Subject: RE: [clue] propose "mutually = exclusive" attribute toreplace simutaneous = sets

 

Hi,

The simultaneous = discussion is about describing physical constrains while audio and video = connection is application connection.

I am not sure if the = audio video should be part of the physical constrains. Also note that = the SDP grouping already provides for it, but if you want it in CLUE it = should be s different attribute.

Roni = Even

 

From:= = Johan Ludvig Nielsen (johaniel) [mailto:johaniel@cisco.com] =
Sent: Friday, March 02, 2012 5:43 PM
To: Duckworth, = Mark; Roni Even; clue@ietf.org
Subject: RE: = [clue] propose "mutually exclusive" attribute toreplace = simutaneous sets

 

Hi

 

I think it would be = useful to include audio and connection between audio and video in this = discussion.

 

Can the = simultaneous  or mutually-exclusive sets be used to specify which = audio captures can be used with which video captures, and which = cannot?

 

This could solve the = case in 11.1 where the connection through the capture area is = insufficient for some captures, as I have pointed out in an earlier post = on the spatial relationships.

 

Regards

Johan

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: 1. mars 2012 = 00:48
To: Roni Even; clue@ietf.org
Subject: Re: = [clue] propose "mutually exclusive" attribute toreplace = simutaneous sets

 

Hi,

For this example it = would be a little simpler like this:

VC1 – = mutually-exclusive=3D{VC5}

VC3 = – mutually-exclusive=3D{VC5}

VC4 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC1,VC3,VC4}

 

The point for = scalability was to simplify a case like this:

VC1 – = mutually-exclusive=3D{VC2}

VC2 = – mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC4}

VC4 = – mutually-exclusive=3D{VC3}

VC5 – = mutually-exclusive=3D{VC6}

VC6 = – mutually-exclusive=3D{VC5}

 

In simultaneous sets it = would have been:

{VC1, VC3, VC5}

{VC1, VC4, = VC5}

{VC1, VC3, VC6}

{VC1, VC4, = VC6}

{VC2, VC3, VC5}

{VC2, VC4, = VC5}

{VC2, VC3, VC6}

{VC2, VC4, = VC6}

 

Adding another mutually = exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs = each.

 

I agree the framework = should clarify that capture set entries are the provider’s = suggestion to the consumer about which media captures would be most = useful to receive together.

 

I agree the framework = should clarify that the consumer can choose just part of a capture set = entry.

 

The consumer can also = pick and choose media captures from different capture set entries, and = for this case the mutually exclusive information becomes = important.

 

Mark

 

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]=
Sent: Wednesday, February 29, 2012 6:08 PM
To: = Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

Hi,

I do not think = that changes anything since this is the complement of the simultaneous = set and will be less condensed.

For = example taking the example from the framework in section = 11.1

 

  = ; The physical simultaneity information is:

 =

  = ;    {VC0, VC1, VC2, VC3, VC4, = VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Your = proposal will require

VC1 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC3}

VC4 = – mutually-exclusive=3D{VC5}

VC5– mutually-exclusive=3D{VC4}

And the result is the same since it can be translated = to the current description.

 

My proposal = was to clarify in the framework that  the capture set entries are = the preferred mode as proposed by the provider. Also to say that a = consumer can select part of a capture set entry or simultaneous = set.

 

Roni

 

 

 =

 =

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Thursday, March 01, = 2012 12:43 AM
To: clue@ietf.org
Subject: = [clue] propose "mutually exclusive" attribute to replace = simutaneous sets

 

This is a = proposal from all the framework authors.  Please = review.

 

We propose removing the concept of “simultaneous = sets” and replacing it with a new media capture attribute called = “mutually exclusive”.  The purpose is to have a more = concise way to indicate which media captures cannot be used at the same = time, which we believe scales better than the simultaneous set idea when = there are multiple mutually exclusive constraints.  This is in = response to concerns discussed at the interim meeting about scalability = of simultaneous sets, and confusion between simultaneous sets and = capture set entries.

 

New Media = Capture attribute:

 

Mutually-exclusive: {list of MCs that cannot be used = at same time as this MC}

 

Consider the = example of a room system where there are 3 cameras each

of which can send a separate capture covering 2 = persons each- VC0,

VC1, VC2. The = middle camera can also zoom out and show all 6

persons, VC3. But the middle camera cannot be used in = both modes at

the same time - it has = to either show the space where 2 participants

sit or the whole 6 seats, but not both at the same = time.

 

The provider specifies this with the following video = capture attribute values:

VC1 – = mutually-exclusive=3D{VC3}

VC3 = – mutually-exclusive=3D{VC1}

 

A provider = must advertise mutually exclusive attributes that allow all the media = captures in a capture set entry to be used at the same = time.

 

Section 6.3 “Simultaneous Transmission Set = Constraints” can be removed.

We = will update the example in section 11.1 to show the new attribute rather = than the simultaneous sets.

 

Mark

 

------_=_NextPart_001_01CCFB9F.1FCC5BCE-- From allyn@cisco.com Tue Mar 6 08:10:25 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B3621F86CE for ; Tue, 6 Mar 2012 08:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.165 X-Spam-Level: X-Spam-Status: No, score=-10.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeQpten-B29V for ; Tue, 6 Mar 2012 08:10:20 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEE821F8803 for ; Tue, 6 Mar 2012 08:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=29797; q=dns/txt; s=iport; t=1331050220; x=1332259820; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Te3/6398SoRpQAKTlF17NGV8HkIoESz23buBt3Y2TM0=; b=hwkqxaf7pzqojTGDF0WCfZWRiDEJPHTgVSMxrq2F4yjEbA9gUQaPsvvL ra1rFzXOdPUvRcJAi4FpmPHTBuQ9Pd95cQ1wydMcv5QXQIb7psWl/uhj3 8BXlh4bSpCdJYkrsH8Z/iQMpGDhjXRGwfXfLdlhmcdEV+H0r9VCbsNJwL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADU2Vk+rRDoG/2dsb2JhbABDglKyJoEHgX0BAQEEEgEJEQNZAgEIDgMEAQELBhAHAQYBICUJCAEBBAESCBqHZAGgagGXLYk7hkBjBIhSmA2EdoME X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208,217";a="34667285" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 16:10:20 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q26GAJod015727; Tue, 6 Mar 2012 16:10:19 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 08:10:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFBB3.A047FB95" Date: Tue, 6 Mar 2012 08:10:17 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC06EEBB89@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4f4ebef7.85600e0a.5242.0772@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets Thread-Index: Acz3MQwPAsai6Sr5R62dhdvpm7sRIgABIgOgAAFYB3AAALjf0AEc+CDg References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7375@CRPMBOXPRD01.polycom.com><4f4eb007.85600e0a.1d16.74b8@mx.google.com><44C6B6B2D0CF424AA90B6055548D7A6102FB6C73A5@CRPMBOXPRD01.polycom.com> <4f4ebef7.85600e0a.5242.0772@mx.google.com> From: "Allyn Romanow (allyn)" To: "Roni Even" , "Duckworth, Mark" , X-OriginalArrivalTime: 06 Mar 2012 16:10:19.0889 (UTC) FILETIME=[A0974E10:01CCFBB3] Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:10:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFBB3.A047FB95 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, =20 I think that your note really hits the nail on the head. As Mark said, the purpose of moving simultaneous set info into the media capture attributes was two fold - first to be more parsimonious, and secondly to avoid confusion. =20 By having both capture sets and simultaneous transmission sets, we have created confusion as to how the consumer chooses sets.=20 We had meant it to be that the consumer chooses based on capture set, and applies the rules from the simultaneous set to that choice. But this was not a good idea. People could look at the 2 sets of captures and say, I'm going to ignore capture set and just use the simultaneous set. So it really wasn't a good idea to have two sets of captures.=20 =20 The information that needs to be conveyed falls easily within the notion of an attribute of a media capture. That way there is no confusion with two sets of captures, but the necessary mutual exclusivity is communicated. =20 I'll respond to your comments below- =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, February 29, 2012 4:12 PM To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] propose "mutually exclusive" attribute toreplace simutaneous sets =20 Mark, The simultaneous case in the example that I listed are in the document and are built on a use case, this example has two lines for simultaneous sets and 4 using the mutually exclusive description .=20 I am not sure what use case you are describing. Anyhow, like I said before these two option are complements to one another and my view is that simultaneous sets make more sense in term of readability and I see no reason to change the current description. =20 AR- As I described above the reason to change is to avoid confusion about consumer choice. An additional reason is parsimoniousness (is that a word?), which Mark has argued in previous emails. =20 You did not address the point I made about clarifying that a consumer can select part of the capture set entry or request one that is not defined as long as it does not contradict the simultaneously regardless of which presentation we select. If this is correct is simpler to construct the allowed sets from the current presentations since you just select a simultaneous set or part of it. =20 AR- A consumer can select part of the capture set entry - unfortunately. Unfortunately because each entry is a representation of the scene, so it would be better to choose a full representation. But, we didn't think it right to restrict the ability of the consumer to choose from an entry. As for requesting something that is not defined.. no- not correct- that's not included. The consumer can't request an entry not defined. I probably don't know what you mean, as how could it request an undefined capture? In terms of an undefined entry.. what does tat mean?.. the consumer can pick and choose any of the captures in the capture set as long as it stays within the exclusivity rules (however they are expressed). The entries are the information from the provider that this group of captures represents the scene. =20 Regards, Allyn =20 =20 Roni=20 =20 From: Duckworth, Mark [mailto:Mark.Duckworth@polycom.com]=20 Sent: Thursday, March 01, 2012 1:48 AM To: Roni Even; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simutaneous sets =20 Hi, For this example it would be a little simpler like this: VC1 - mutually-exclusive=3D{VC5} VC3 - mutually-exclusive=3D{VC5} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1,VC3,VC4} =20 The point for scalability was to simplify a case like this: VC1 - mutually-exclusive=3D{VC2} VC2 - mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC4} VC4 - mutually-exclusive=3D{VC3} VC5 - mutually-exclusive=3D{VC6} VC6 - mutually-exclusive=3D{VC5} =20 In simultaneous sets it would have been: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 Adding another mutually exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs each. =20 I agree the framework should clarify that capture set entries are the provider's suggestion to the consumer about which media captures would be most useful to receive together. =20 I agree the framework should clarify that the consumer can choose just part of a capture set entry. =20 The consumer can also pick and choose media captures from different capture set entries, and for this case the mutually exclusive information becomes important. =20 Mark =20 =20 =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Wednesday, February 29, 2012 6:08 PM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] propose "mutually exclusive" attribute to replace simutaneous sets =20 Hi, I do not think that changes anything since this is the complement of the simultaneous set and will be less condensed. For example taking the example from the framework in section 11.1 =20 The physical simultaneity information is: =20 {VC0, VC1, VC2, VC3, VC4, VC6} =20 {VC0, VC2, VC5, VC6} =20 Your proposal will require VC1 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC1} VC3 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC3} VC4 - mutually-exclusive=3D{VC5} VC5- mutually-exclusive=3D{VC4} And the result is the same since it can be translated to the current description. =20 My proposal was to clarify in the framework that the capture set entries are the preferred mode as proposed by the provider. Also to say that a consumer can select part of a capture set entry or simultaneous set. =20 Roni =20 =20 =20 =20 =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, March 01, 2012 12:43 AM To: clue@ietf.org Subject: [clue] propose "mutually exclusive" attribute to replace simutaneous sets =20 This is a proposal from all the framework authors. Please review. =20 We propose removing the concept of "simultaneous sets" and replacing it with a new media capture attribute called "mutually exclusive". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. This is in response to concerns discussed at the interim meeting about scalability of simultaneous sets, and confusion between simultaneous sets and capture set entries. =20 New Media Capture attribute: =20 Mutually-exclusive: {list of MCs that cannot be used at same time as this MC} =20 Consider the example of a room system where there are 3 cameras each of which can send a separate capture covering 2 persons each- VC0, VC1, VC2. The middle camera can also zoom out and show all 6 persons, VC3. But the middle camera cannot be used in both modes at the same time - it has to either show the space where 2 participants sit or the whole 6 seats, but not both at the same time. =20 The provider specifies this with the following video capture attribute values: VC1 - mutually-exclusive=3D{VC3} VC3 - mutually-exclusive=3D{VC1} =20 A provider must advertise mutually exclusive attributes that allow all the media captures in a capture set entry to be used at the same time. =20 Section 6.3 "Simultaneous Transmission Set Constraints" can be removed. We will update the example in section 11.1 to show the new attribute rather than the simultaneous sets. =20 Mark =20 ------_=_NextPart_001_01CCFBB3.A047FB95 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Roni,

 

I think that your = note really hits the nail on the head.

As Mark said, the = purpose of moving simultaneous set info into the media capture attributes was two = fold – first to be more parsimonious, and secondly to avoid = confusion.

 

By having both = capture sets and simultaneous transmission sets, we have created confusion as to how the consumer chooses sets.

We had meant it to be = that the consumer chooses based on capture set, and applies the rules from the simultaneous set to that choice. But this was not a good idea. People = could look at the 2 sets of captures and say, I’m going to ignore = capture set and just use the simultaneous set. So it really wasn’t a good idea = to have two sets of captures.

 

The information that = needs to be conveyed falls easily within the notion of an attribute of a media = capture. That way there is no confusion with two sets of captures, but the necessary = mutual exclusivity is communicated.

 

I’ll respond to = your comments below-

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, February 29, 2012 4:12 PM
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] propose "mutually exclusive" = attribute toreplace simutaneous sets

 

Mark,

The simultaneous case = in the example that I listed are in the document and are built on a use case, = this example has two lines for simultaneous sets and 4 using the mutually = exclusive description .

I am not sure what = use case you are describing.

Anyhow, like I said = before these two option are complements to one another and my view is that = simultaneous sets make more sense in term of readability and I see no reason to change the current description.

 

AR- As I described = above the reason to change is to avoid confusion about consumer choice. An = additional reason is parsimoniousness (is that a word?), which Mark has argued in = previous emails.

 

You did not address = the point I made about clarifying that a consumer can select part of the capture set = entry or request one that is not defined as long as it does not contradict the simultaneously regardless of which presentation we select.  If this = is correct is simpler to construct the allowed sets from the current = presentations since you just select a simultaneous set or part of it.

 

AR- A consumer can = select part of the capture set entry – unfortunately. Unfortunately because = each entry is a representation of the scene, so it would be better to choose = a full representation. But, we didn’t think it right to restrict the = ability of the consumer to choose from an entry.

As for requesting = something that is not defined.. no- not correct- that’s not included. The = consumer can’t request an entry not defined.  I probably don’t know what you = mean, as how could it  request an undefined capture?  In terms of an undefined entry.. what does tat mean?..  the consumer can pick and = choose any of the captures in the capture set as long as it stays within the exclusivity rules (however they are expressed). The entries are the = information from the provider that this group of captures represents the = scene.

 

Regards,

Allyn

 

 

Roni =

 

From:= Duckworth, = Mark [mailto:Mark.Duckworth@polycom.com]
Sent: Thursday, March 01, 2012 1:48 AM
To: Roni Even; clue@ietf.org
Subject: RE: [clue] propose "mutually exclusive" = attribute to replace simutaneous sets

 

Hi,

For this example it = would be a little simpler like this:

VC1 – = mutually-exclusive=3D{VC5}

VC3 – = mutually-exclusive=3D{VC5}

VC4 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC1,VC3,VC4}

 

The point for = scalability was to simplify a case like this:

VC1 – = mutually-exclusive=3D{VC2}

VC2 – = mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC4}

VC4 – = mutually-exclusive=3D{VC3}

VC5 – = mutually-exclusive=3D{VC6}

VC6 – = mutually-exclusive=3D{VC5}

 

In simultaneous sets = it would have been:

{VC1, VC3, = VC5}

{VC1, VC4, = VC5}

{VC1, VC3, = VC6}

{VC1, VC4, = VC6}

{VC2, VC3, = VC5}

{VC2, VC4, = VC5}

{VC2, VC3, = VC6}

{VC2, VC4, = VC6}

 

Adding another = mutually exclusive pair would expand the simultaneous sets to 16 sets of 4 VCs = each.

 

I agree the framework = should clarify that capture set entries are the provider’s suggestion to = the consumer about which media captures would be most useful to receive = together.

 

I agree the framework = should clarify that the consumer can choose just part of a capture set = entry.

 

The consumer can also = pick and choose media captures from different capture set entries, and for this = case the mutually exclusive information becomes important.

 

Mark

 

 

 

From:= Roni Even = [mailto:ron.even.tlv@gmail.com]=
Sent: Wednesday, February 29, 2012 6:08 PM
To: Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] propose "mutually exclusive" = attribute to replace simutaneous sets

 

Hi,

I do not think that changes anything since this is = the complement of the simultaneous set and will be less = condensed.

For example taking the example from the framework = in section 11.1

 

  = ; The physical simultaneity information is:

 =

  = ;    {VC0, VC1, VC2, VC3, VC4, VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Your proposal will require

VC1 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC1}

VC3 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC3}

VC4 – = mutually-exclusive=3D{VC5}

VC5– = mutually-exclusive=3D{VC4}

And the result is the same since it can be = translated to the current description.

 

My proposal was to clarify in the framework that =  the capture set entries are the preferred mode as proposed by the provider. = Also to say that a consumer can select part of a capture set entry or = simultaneous set.

 

Roni

 

 

 =

 =

 

 

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Thursday, March 01, 2012 12:43 AM
To: clue@ietf.org
Subject: [clue] propose "mutually exclusive" attribute = to replace simutaneous sets

 

This is a proposal from all the framework = authors.  Please review.

 

We propose removing the concept of = “simultaneous sets” and replacing it with a new media capture attribute called “mutually exclusive”.  The purpose is to have a more = concise way to indicate which media captures cannot be used at the same time, = which we believe scales better than the simultaneous set idea when there are = multiple mutually exclusive constraints.  This is in response to concerns = discussed at the interim meeting about scalability of simultaneous sets, and = confusion between simultaneous sets and capture set entries.

 

New Media Capture attribute:

 

Mutually-exclusive: {list of MCs that cannot be = used at same time as this MC}

 

Consider the example of a room system where there = are 3 cameras each

of which can send a separate capture covering 2 = persons each- VC0,

VC1, VC2. The middle camera can also zoom out and = show all 6

persons, VC3. But the middle camera cannot be used = in both modes at

the same time - it has to either show the space = where 2 participants

sit or the whole 6 seats, but not both at the same = time.

 

The provider specifies this with the following = video capture attribute values:

VC1 – = mutually-exclusive=3D{VC3}

VC3 – = mutually-exclusive=3D{VC1}

 

A provider must advertise mutually exclusive = attributes that allow all the media captures in a capture set entry to be used at the = same time.

 

Section 6.3 “Simultaneous Transmission Set Constraints” can be removed.

We will update the example in section 11.1 to show = the new attribute rather than the simultaneous sets.

 

Mark

 

------_=_NextPart_001_01CCFBB3.A047FB95-- From john@jlc.net Tue Mar 6 08:14:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8E721F896B for ; Tue, 6 Mar 2012 08:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.333 X-Spam-Level: X-Spam-Status: No, score=-106.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8muBU0VfJKvQ for ; Tue, 6 Mar 2012 08:14:39 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2C70C21F896A for ; Tue, 6 Mar 2012 08:14:39 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1047733CA5; Tue, 6 Mar 2012 11:14:39 -0500 (EST) Date: Tue, 6 Mar 2012 11:14:39 -0500 From: John Leslie To: Roni even Message-ID: <20120306161438.GF77987@verdi> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F93@CRPMBOXPRD01.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: "clue@ietf.org" Subject: Re: [clue] Ticket #7 composed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 16:14:39 -0000 Roni even wrote: > [Mark.Duckworth@polycom.com wrote:] >> >> My recollection is that the people in the meeting generally agreed on this. >> So it seems to me this is the resolution of ticket #7. Is that correct? > > This is not my recollection. It is OK to have a Boolean as long as we > have an attribute that provide information about the composition in the > framework document or we need to change the composed attribute. I see little value in anything between a simple boolean and a list of elements composing the stream; but I would like to have an option to specify that list defined. -- John Leslie From pkyzivat@alum.mit.edu Tue Mar 6 12:07:12 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BCF21E80C8 for ; Tue, 6 Mar 2012 12:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeQPciOmQd6H for ; Tue, 6 Mar 2012 12:07:11 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 24A7721E80C4 for ; Tue, 6 Mar 2012 12:07:10 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id iK9s1i0071YDfWL5DL7BVx; Tue, 06 Mar 2012 20:07:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id iL7B1i00J07duvL3gL7BtZ; Tue, 06 Mar 2012 20:07:11 +0000 Message-ID: <4F566E6D.8050104@alum.mit.edu> Date: Tue, 06 Mar 2012 15:07:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:07:12 -0000 On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: > Hey Roni, > > I think this is just a vocabulary change—multiple capture scenes are > still allowed. The idea was that the ‘purpose’ attribute of the capture > scene would be used to differentiate them. A scene represents a physical (or virtually physical) space that is represented by one or more captures. If an endpoint has available and wants to advertise representations of more than one such space then it will be including more than one capture scene in its advertisement. The 'purpose' attribute won't always be sufficient to disambiguate the scenes. One case where 'purpose' *would* be enough is when one scene is 'main' representing a single room, and another is 'presentation'. A case where it *isn't* enough is when the endpoint is an MCU and it wants to offer to "pass through" a scene for each connected room. In that case, each of those scenes will probably have purpose 'main'. There probably needs to be some other attribute that describes the scene - perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom Andover", ...) Or there could be a more complex attribute that describes location. Thanks, Paul > -Brian > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Roni Even > *Sent:* Tuesday, March 06, 2012 12:23 AM > *To:* 'Duckworth, Mark'; clue@ietf.org > *Subject:* Re: [clue] Proposal to combine capture scene and capture set > > Hi Mark, > > I do not care how we call it. What I am missing is the top level. > > Does a provider advertise one capture scene composed of multiple capture > scene entries. My understanding so far was that there can be more than > one if we substitute set with scene. > > Can there be more than one capture scene in the advertisement in which > case how do you differentiate between them, is there a scene identifier > and how does the consumer know what is the scene. > > Roni Even > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] > *On Behalf Of *Duckworth, Mark > *Sent:* Monday, March 05, 2012 9:16 PM > *To:* clue@ietf.org > *Subject:* [clue] Proposal to combine capture scene and capture set > > At the interim meeting, there was some support for combining the > concepts of “capture scene” and “capture set” into a single concept. So > here is a rough proposal for doing that, essentially using the term > “capture scene” to replace the previous term “capture set”, and > eliminating the original separate capture scene concept. > > Definitions: > > *Capture Scene: a structure representing the scene that is captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. > > *Capture Scene Entry: a list of media captures of the same media type > that together form one way to represent the capture scene. > > Text for section 6.2 Capture Scene (was 6.2 Capture Set): > > A capture scene represents, for example, the video image of a group of > people seated next to each other, along with the sound of their voices, > which could be represented by some number of VCs and ACs in the capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives. > > A media provider arranges media captures in a capture scene to help the > media consumer choose which captures it wants. The capture scene entries > in a capture scene are different alternatives the provider is suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each media > type (e.g. audio and video), or it can pick and choose media captures > regardless of how the provider arranges them in capture scene entries. > > A capture scene may include more than one type of media. For example, a > capture scene can include several capture scene entries for video > captures, and several capture scene entries for audio captures. > > (This text would be worked into section 6.2, not replace it completely. > Other things in section 6.2 and elsewhere would need to be edited to be > consistent with the new terminology in this proposal) > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Mar 6 12:31:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3457C21E80AF for ; Tue, 6 Mar 2012 12:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NjY5gFsyqo0 for ; Tue, 6 Mar 2012 12:31:16 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4E40621E8024 for ; Tue, 6 Mar 2012 12:31:16 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id iH6o1i0021c6gX855LXGxz; Tue, 06 Mar 2012 20:31:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id iLXG1i01A07duvL3jLXGbe; Tue, 06 Mar 2012 20:31:16 +0000 Message-ID: <4F567412.7090506@alum.mit.edu> Date: Tue, 06 Mar 2012 15:31:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:31:17 -0000 On 3/5/12 2:16 PM, Duckworth, Mark wrote: > At the interim meeting, there was some support for combining the > concepts of “capture scene” and “capture set” into a single concept. So > here is a rough proposal for doing that, essentially using the term > “capture scene” to replace the previous term “capture set”, and > eliminating the original separate capture scene concept. > > Definitions: > > *Capture Scene: a structure representing the scene that is captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. > > *Capture Scene Entry: a list of media captures of the same media type > that together form one way to represent the capture scene. One of the reasons I preferred "Capture Scene" to "Capture Set" is that "set" implied to me that it is *only* a set of captures. But in fact there are already other attributes in addition to the set of captures (such as the purpose), and there will probably be more as we proceed. To me, "Capture Scene Entry" conveys some of that same assumption. Namely, that a Capture Scene" is made up of a number of Capture Scene Entries, which seems to exclude other attributes that are not Capture Scene Entries. It would feel more natural to me to have a Capture Set that is a set of media captures. (That is, what was previously called a Capture Set Entry.) And then define another term for a grouping of these Capture Sets. I'm having trouble coming up with a term for that which matches the intent well, but as a swag, how about Capture Set Alternatives. So then you would have a logical structure something like: - Advertisement - Capture Scene (one or more) - Description - Purpose - Area of Scene - Capture Set Alternatives (one or more) - Capture Set (one or more) - Capture I don't think Capture Set Alternatives is the right term. I think I am hampered in finding a better term by not really having a crisp understanding of the reason for having this grouping. Its partly about alternatives in that there is an expectation that for a particular medium you would choose only one. But its not about alternatives in that you need to choose audio and video independently. Also, that is only an approximation - there seem to be expected cases when entries from more than one video entry would be chosen. In my experience, when its hard to find a good term it usually means that the thing being named is not sufficiently defined and likely can be factored into more meaningful pieces. Thanks, Paul > Text for section 6.2 Capture Scene (was 6.2 Capture Set): > > A capture scene represents, for example, the video image of a group of > people seated next to each other, along with the sound of their voices, > which could be represented by some number of VCs and ACs in the capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives. > > A media provider arranges media captures in a capture scene to help the > media consumer choose which captures it wants. The capture scene entries > in a capture scene are different alternatives the provider is suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each media > type (e.g. audio and video), or it can pick and choose media captures > regardless of how the provider arranges them in capture scene entries. > > A capture scene may include more than one type of media. For example, a > capture scene can include several capture scene entries for video > captures, and several capture scene entries for audio captures. > > (This text would be worked into section 6.2, not replace it completely. > Other things in section 6.2 and elsewhere would need to be edited to be > consistent with the new terminology in this proposal) > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Tue Mar 6 13:56:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7759B21F85D5 for ; Tue, 6 Mar 2012 13:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.587 X-Spam-Level: X-Spam-Status: No, score=-106.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHdPDSg8xtjw for ; Tue, 6 Mar 2012 13:56:43 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71121F85B5 for ; Tue, 6 Mar 2012 13:56:43 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H0021RGYG7G@szxga05-in.huawei.com> for clue@ietf.org; Wed, 07 Mar 2012 05:56:41 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0H00F37GYGON@szxga05-in.huawei.com> for clue@ietf.org; Wed, 07 Mar 2012 05:56:40 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH03810; Wed, 07 Mar 2012 05:56:26 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 05:55:45 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 07 Mar 2012 05:56:24 +0800 Date: Tue, 06 Mar 2012 21:56:24 +0000 From: Roni even In-reply-to: <4F566E6D.8050104@alum.mit.edu> X-Originating-IP: [172.24.1.46] To: Paul Kyzivat , "clue@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [clue] Proposal to combine capture scene and capture set Thread-index: AQHM+9S71unARYhJGkGydzRjRScQHpZdz08F X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> <4F566E6D.8050104@alum.mit.edu> Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:56:44 -0000 Hi Paul, I think that the MCU case you described should be handled differently. In c= urrent solutions if the MCU wants to provide information about all the meet= ing participants it is done using the conferencing event package. This help= s with addressing large messages and also work with partial notification wh= en a user joins or leave as specified in the XCON conference event package. Roni Even ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Tuesday, March 06, 2012 22:07 To: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: > Hey Roni, > > I think this is just a vocabulary change=97multiple capture scenes are > still allowed. The idea was that the =91purpose=92 attribute of the captu= re > scene would be used to differentiate them. A scene represents a physical (or virtually physical) space that is represented by one or more captures. If an endpoint has available and wants to advertise representations of more than one such space then it will be including more than one capture scene in its advertisement. The 'purpose' attribute won't always be sufficient to disambiguate the scenes. One case where 'purpose' *would* be enough is when one scene is 'main' representing a single room, and another is 'presentation'. A case where it *isn't* enough is when the endpoint is an MCU and it wants to offer to "pass through" a scene for each connected room. In that case, each of those scenes will probably have purpose 'main'. There probably needs to be some other attribute that describes the scene - perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom Andover", ...) Or there could be a more complex attribute that describes location. Thanks, Paul > -Brian > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Roni Even > *Sent:* Tuesday, March 06, 2012 12:23 AM > *To:* 'Duckworth, Mark'; clue@ietf.org > *Subject:* Re: [clue] Proposal to combine capture scene and capture set > > Hi Mark, > > I do not care how we call it. What I am missing is the top level. > > Does a provider advertise one capture scene composed of multiple capture > scene entries. My understanding so far was that there can be more than > one if we substitute set with scene. > > Can there be more than one capture scene in the advertisement in which > case how do you differentiate between them, is there a scene identifier > and how does the consumer know what is the scene. > > Roni Even > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] > *On Behalf Of *Duckworth, Mark > *Sent:* Monday, March 05, 2012 9:16 PM > *To:* clue@ietf.org > *Subject:* [clue] Proposal to combine capture scene and capture set > > At the interim meeting, there was some support for combining the > concepts of =93capture scene=94 and =93capture set=94 into a single conce= pt. So > here is a rough proposal for doing that, essentially using the term > =93capture scene=94 to replace the previous term =93capture set=94, and > eliminating the original separate capture scene concept. > > Definitions: > > *Capture Scene: a structure representing the scene that is captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. > > *Capture Scene Entry: a list of media captures of the same media type > that together form one way to represent the capture scene. > > Text for section 6.2 Capture Scene (was 6.2 Capture Set): > > A capture scene represents, for example, the video image of a group of > people seated next to each other, along with the sound of their voices, > which could be represented by some number of VCs and ACs in the capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives. > > A media provider arranges media captures in a capture scene to help the > media consumer choose which captures it wants. The capture scene entries > in a capture scene are different alternatives the provider is suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each media > type (e.g. audio and video), or it can pick and choose media captures > regardless of how the provider arranges them in capture scene entries. > > A capture scene may include more than one type of media. For example, a > capture scene can include several capture scene entries for video > captures, and several capture scene entries for audio captures. > > (This text would be worked into section 6.2, not replace it completely. > Other things in section 6.2 and elsewhere would need to be edited to be > consistent with the new terminology in this proposal) > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From pkyzivat@alum.mit.edu Tue Mar 6 14:30:25 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F63921E8043 for ; Tue, 6 Mar 2012 14:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUndlHgxL31I for ; Tue, 6 Mar 2012 14:30:24 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCE021E8034 for ; Tue, 6 Mar 2012 14:30:23 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta12.westchester.pa.mail.comcast.net with comcast id iNVd1i00317dt5G5CNWQJj; Tue, 06 Mar 2012 22:30:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id iNWP1i00r07duvL3ZNWPdC; Tue, 06 Mar 2012 22:30:24 +0000 Message-ID: <4F568FFE.2020504@alum.mit.edu> Date: Tue, 06 Mar 2012 17:30:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Roni even References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> <4F566E6D.8050104@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:30:25 -0000 On 3/6/12 4:56 PM, Roni even wrote: > Hi Paul, > I think that the MCU case you described should be handled differently. In current solutions if the MCU wants to provide information about all the meeting participants it is done using the conferencing event package. This helps with addressing large messages and also work with partial notification when a user joins or leave as specified in the XCON conference event package. While I understand that the conference event package is applicable, I don't see how it is a substitute for what I described. If the MCU is the recipient of captures from multiple scenes (and it always will be), then what does it advertise? I guess there are multiple answers to that: - it can create a single scene representing a "virtual room", with a single coordinate space. It can then map all the captures onto that coordinate space. In that case it only needs one scene, for the 'main' stuff. And I guess it could do that for other purposes as well, creating one virtual scene per purpose. - it can do as I suggested, offering up each of the scenes it has received. Thus there can be several scenes for each purpose. Thanks, Paul > Roni Even > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Tuesday, March 06, 2012 22:07 > To: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: >> Hey Roni, >> >> I think this is just a vocabulary change—multiple capture scenes are >> still allowed. The idea was that the ‘purpose’ attribute of the capture >> scene would be used to differentiate them. > > A scene represents a physical (or virtually physical) space that is > represented by one or more captures. If an endpoint has available and > wants to advertise representations of more than one such space then it > will be including more than one capture scene in its advertisement. The > 'purpose' attribute won't always be sufficient to disambiguate the scenes. > > One case where 'purpose' *would* be enough is when one scene is 'main' > representing a single room, and another is 'presentation'. > > A case where it *isn't* enough is when the endpoint is an MCU and it > wants to offer to "pass through" a scene for each connected room. In > that case, each of those scenes will probably have purpose 'main'. There > probably needs to be some other attribute that describes the scene - > perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom > Andover", ...) Or there could be a more complex attribute that describes > location. > > Thanks, > Paul > >> -Brian >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Roni Even >> *Sent:* Tuesday, March 06, 2012 12:23 AM >> *To:* 'Duckworth, Mark'; clue@ietf.org >> *Subject:* Re: [clue] Proposal to combine capture scene and capture set >> >> Hi Mark, >> >> I do not care how we call it. What I am missing is the top level. >> >> Does a provider advertise one capture scene composed of multiple capture >> scene entries. My understanding so far was that there can be more than >> one if we substitute set with scene. >> >> Can there be more than one capture scene in the advertisement in which >> case how do you differentiate between them, is there a scene identifier >> and how does the consumer know what is the scene. >> >> Roni Even >> >> *From:*clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] >> *On Behalf Of *Duckworth, Mark >> *Sent:* Monday, March 05, 2012 9:16 PM >> *To:* clue@ietf.org >> *Subject:* [clue] Proposal to combine capture scene and capture set >> >> At the interim meeting, there was some support for combining the >> concepts of “capture scene” and “capture set” into a single concept. So >> here is a rough proposal for doing that, essentially using the term >> “capture scene” to replace the previous term “capture set”, and >> eliminating the original separate capture scene concept. >> >> Definitions: >> >> *Capture Scene: a structure representing the scene that is captured by a >> collection of capture devices. A capture scene includes one or more >> capture scene entries, with each entry including one or more media >> captures. >> >> *Capture Scene Entry: a list of media captures of the same media type >> that together form one way to represent the capture scene. >> >> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >> >> A capture scene represents, for example, the video image of a group of >> people seated next to each other, along with the sound of their voices, >> which could be represented by some number of VCs and ACs in the capture >> scene entries. A middle box may also express capture scenes that it >> constructs from media streams it receives. >> >> A media provider arranges media captures in a capture scene to help the >> media consumer choose which captures it wants. The capture scene entries >> in a capture scene are different alternatives the provider is suggesting >> for representing the capture scene. The media consumer can choose to >> receive all media captures from one capture scene entry for each media >> type (e.g. audio and video), or it can pick and choose media captures >> regardless of how the provider arranges them in capture scene entries. >> >> A capture scene may include more than one type of media. For example, a >> capture scene can include several capture scene entries for video >> captures, and several capture scene entries for audio captures. >> >> (This text would be worked into section 6.2, not replace it completely. >> Other things in section 6.2 and elsewhere would need to be edited to be >> consistent with the new terminology in this proposal) >> >> Regards, >> >> Mark >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Mar 6 14:51:59 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457A521E8034 for ; Tue, 6 Mar 2012 14:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phQ2Y7Bxnd2N for ; Tue, 6 Mar 2012 14:51:58 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF3621E8014 for ; Tue, 6 Mar 2012 14:51:58 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta06.westchester.pa.mail.comcast.net with comcast id iNiD1i0040SCNGk56NryPN; Tue, 06 Mar 2012 22:51:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta09.westchester.pa.mail.comcast.net with comcast id iNry1i01C07duvL3VNry6u; Tue, 06 Mar 2012 22:51:58 +0000 Message-ID: <4F56950D.2000302@alum.mit.edu> Date: Tue, 06 Mar 2012 17:51:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Duckworth, Mark" References: <44C6B6B2D0CF424AA90B6055548D7A6102FB5E0185@CRPMBOXPRD01.polycom.com> <4F4E4A81.6070006@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB5E021D@CRPMBOXPRD01.polycom.com> <4F4FEFCD.7000806@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F9F@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C7F9F@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Language re capture axis X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:51:59 -0000 On 3/5/12 1:29 PM, Duckworth, Mark wrote: > As editor, it seems I should leave this out of the next version. Okay? I'm ok with leaving any mention of it out, assuming those who were concerned about it (Stephan) are ok with that. Paul > Otherwise, I would appreciate having interested parties propose new text to discuss on the mailing list, considering Paul's desire to have more specific text than what we have previously discussed. > > Thanks, > Mark > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, March 01, 2012 4:53 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: [clue] Language re capture axis >> >> On 2/29/12 11:14 AM, Duckworth, Mark wrote: >>> Paul and Stephan, >>> >>> Personally, I'd rather just leave it out altogether because I think it doesn't >> add anything that needs to be standardized. But Stephan thought it was >> important, so I was trying to find a way to say it in an "accurate enough" way. >> >> If there is no widespread interest in having this, and those who have asked >> about it are happy without, then I'm fine with leaving it out. >> >> If it is to be mentioned, with the idea that the recipient might use it for >> something, then I think it should be made clear how it can be determined. >> >> Thanks, >> Paul >> >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Paul Kyzivat >>>> Sent: Wednesday, February 29, 2012 10:56 AM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Language re capture axis >>>> >>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: >>>>> Hi Stephan, >>>>> >>>>> I agree in principle with your suggestion, but I think your >>>>> suggested text is not mathematically accurate. I think the axis of >>>>> capture doesn't go to the center of the area of capture. For >>>>> example, if the camera is pointed at the area of capture at an >>>>> angle, the center point of the area would not line up with the >>>>> center point of the camera's field of view (which defines the axis). >>>>> >>>>> So rather than try to get into the mathematical details, how about this: >>>>> >>>>> "Note that, for the purpose of receiver-side geometric correction, >>>>> it can be assumed that the axis of capture of directional capture >>>>> devices (cameras, directional microphones etc.) can be calculated >>>>> from the coordinates of the point of capture and area of capture." >>>> >>>> IMO this is dangerously vague. Presumably there is a real axis of capture. >>>> Hopefully there is a well defined algorithm for deriving the axis >>>> from the available data, so that the recipient will determine the >>>> actual axis. If so, then it should be specified or referenced from >>>> some source. Otherwise we run the risk that not all will correctly derive >> the axis. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Mark >>>>> >>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >>>>> Behalf Of *Stephan Wenger >>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM >>>>> *To:* clue@ietf.org >>>>> *Subject:* [clue] Language re capture axis >>>>> >>>>> Hi, >>>>> >>>>> The issue I mentioned in the meeting is that nowhere in the >>>>> framework (as far as I recall) the axis of capture of a video >>>>> capture (or directional audio capture-anything that is not >>>>> omnidirectional) is undefined. Without that axis being defined, >>>>> receiver-side geometric correction is not possible. >>>>> >>>>> The issue could be solved in two ways: include attributes, per >>>>> capture, indicating angle of capture in 3D space (relative to >>>>> what???), or by making the bold assumption that the coordinates >>>>> defining area of capture plus capture point define the axis of >>>>> capture. I suggest the latter as it is easy to implement and (I >>>>> believe) >>>> practical. >>>>> >>>>> The language could be something like: >>>>> >>>>> " >>>>> >>>>> Note that, for the purpose of receiver-side geometric correction, it >>>>> can be assumed that the axis of capture of directional capture >>>>> devices (cameras, directional microphones etc.) is the line from the >>>>> capture point to the center of the plane of capture. >>>>> >>>>> " >>>>> >>>>> Stephan >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> > > From stewe@stewe.org Tue Mar 6 16:34:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F7721F86A0 for ; Tue, 6 Mar 2012 16:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpAdawW9sfVx for ; Tue, 6 Mar 2012 16:34:41 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49D21F869F for ; Tue, 6 Mar 2012 16:34:41 -0800 (PST) Received: from mail78-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Wed, 7 Mar 2012 00:34:40 +0000 Received: from mail78-ch1 (localhost [127.0.0.1]) by mail78-ch1-R.bigfish.com (Postfix) with ESMTP id 3EE5F3002B6; Wed, 7 Mar 2012 00:34:40 +0000 (UTC) X-SpamScore: -34 X-BigFish: PS-34(zzbb2dI9371I542M1432N98dK4015Izz1202h1082kzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail78-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail78-ch1 (localhost.localdomain [127.0.0.1]) by mail78-ch1 (MessageSwitch) id 1331080478755369_25580; Wed, 7 Mar 2012 00:34:38 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.226]) by mail78-ch1.bigfish.com (Postfix) with ESMTP id A58512E004B; Wed, 7 Mar 2012 00:34:38 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 7 Mar 2012 00:34:38 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.178]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0123.000; Wed, 7 Mar 2012 00:34:36 +0000 From: Stephan Wenger To: Paul Kyzivat , "Duckworth, Mark" Thread-Topic: [clue] Language re capture axis Thread-Index: AQHM6/tnLytIKH/OzUOAFdCyR7eqWJZUDShAgAAQEoCAAAUfgIAB8RuAgAYQXACAAduwgP//lo0A Date: Wed, 7 Mar 2012 00:34:36 +0000 Message-ID: In-Reply-To: <4F56950D.2000302@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <7DC06DC76DD5EE4D871CDBDE6077A7D1@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "clue@ietf.org" Subject: Re: [clue] Language re capture axis X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 00:34:42 -0000 With the understanding that "out of this version" means "out of this interation of the I-D", I'm fine. I still want this in the published RFC. Same goes for (de)composition info. I will propose text as soon as I find the cycles (not before the Paris I-D deadline). Stephan On 3.6.2012 14:51 , "Paul Kyzivat" wrote: >On 3/5/12 1:29 PM, Duckworth, Mark wrote: >> As editor, it seems I should leave this out of the next version. Okay? > >I'm ok with leaving any mention of it out, assuming those who were >concerned about it (Stephan) are ok with that. > > Paul > >> Otherwise, I would appreciate having interested parties propose new >>text to discuss on the mailing list, considering Paul's desire to have >>more specific text than what we have previously discussed. >> >> Thanks, >> Mark >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Thursday, March 01, 2012 4:53 PM >>> To: Duckworth, Mark >>> Cc: clue@ietf.org >>> Subject: Re: [clue] Language re capture axis >>> >>> On 2/29/12 11:14 AM, Duckworth, Mark wrote: >>>> Paul and Stephan, >>>> >>>> Personally, I'd rather just leave it out altogether because I think >>>>it doesn't >>> add anything that needs to be standardized. But Stephan thought it was >>> important, so I was trying to find a way to say it in an "accurate >>>enough" way. >>> >>> If there is no widespread interest in having this, and those who have >>>asked >>> about it are happy without, then I'm fine with leaving it out. >>> >>> If it is to be mentioned, with the idea that the recipient might use >>>it for >>> something, then I think it should be made clear how it can be >>>determined. >>> >>> Thanks, >>> Paul >>> >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>>> Of Paul Kyzivat >>>>> Sent: Wednesday, February 29, 2012 10:56 AM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Language re capture axis >>>>> >>>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: >>>>>> Hi Stephan, >>>>>> >>>>>> I agree in principle with your suggestion, but I think your >>>>>> suggested text is not mathematically accurate. I think the axis of >>>>>> capture doesn't go to the center of the area of capture. For >>>>>> example, if the camera is pointed at the area of capture at an >>>>>> angle, the center point of the area would not line up with the >>>>>> center point of the camera's field of view (which defines the axis). >>>>>> >>>>>> So rather than try to get into the mathematical details, how about >>>>>>this: >>>>>> >>>>>> "Note that, for the purpose of receiver-side geometric correction, >>>>>> it can be assumed that the axis of capture of directional capture >>>>>> devices (cameras, directional microphones etc.) can be calculated >>>>>> from the coordinates of the point of capture and area of capture." >>>>> >>>>> IMO this is dangerously vague. Presumably there is a real axis of >>>>>capture. >>>>> Hopefully there is a well defined algorithm for deriving the axis >>>>> from the available data, so that the recipient will determine the >>>>> actual axis. If so, then it should be specified or referenced from >>>>> some source. Otherwise we run the risk that not all will correctly >>>>>derive >>> the axis. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>>> Mark >>>>>> >>>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >>>>>> Behalf Of *Stephan Wenger >>>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM >>>>>> *To:* clue@ietf.org >>>>>> *Subject:* [clue] Language re capture axis >>>>>> >>>>>> Hi, >>>>>> >>>>>> The issue I mentioned in the meeting is that nowhere in the >>>>>> framework (as far as I recall) the axis of capture of a video >>>>>> capture (or directional audio capture-anything that is not >>>>>> omnidirectional) is undefined. Without that axis being defined, >>>>>> receiver-side geometric correction is not possible. >>>>>> >>>>>> The issue could be solved in two ways: include attributes, per >>>>>> capture, indicating angle of capture in 3D space (relative to >>>>>> what???), or by making the bold assumption that the coordinates >>>>>> defining area of capture plus capture point define the axis of >>>>>> capture. I suggest the latter as it is easy to implement and (I >>>>>> believe) >>>>> practical. >>>>>> >>>>>> The language could be something like: >>>>>> >>>>>> " >>>>>> >>>>>> Note that, for the purpose of receiver-side geometric correction, it >>>>>> can be assumed that the axis of capture of directional capture >>>>>> devices (cameras, directional microphones etc.) is the line from the >>>>>> capture point to the center of the plane of capture. >>>>>> >>>>>> " >>>>>> >>>>>> Stephan >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >> >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue > From Even.roni@huawei.com Tue Mar 6 23:52:08 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D04221F8549 for ; Tue, 6 Mar 2012 23:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.588 X-Spam-Level: X-Spam-Status: No, score=-106.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9PTgMfHanVx for ; Tue, 6 Mar 2012 23:52:07 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id AAAE121F85C2 for ; Tue, 6 Mar 2012 23:52:06 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0I00E1J8GALR@szxga03-in.huawei.com> for clue@ietf.org; Wed, 07 Mar 2012 15:50:34 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0I00L8C8GACK@szxga03-in.huawei.com> for clue@ietf.org; Wed, 07 Mar 2012 15:50:34 +0800 (CST) Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHQ52809; Wed, 07 Mar 2012 15:50:33 +0800 Received: from SZXEML435-HUB.china.huawei.com (10.72.61.63) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 15:49:50 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml435-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 07 Mar 2012 15:50:31 +0800 Date: Wed, 07 Mar 2012 07:50:31 +0000 From: Roni even In-reply-to: <4F568FFE.2020504@alum.mit.edu> X-Originating-IP: [172.24.1.46] To: Paul Kyzivat Message-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: [clue] Proposal to combine capture scene and capture set Thread-index: AQHM+9S71unARYhJGkGydzRjRScQHpZdz08F//+EWgCAAR3XIw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> <4F566E6D.8050104@alum.mit.edu> <4F568FFE.2020504@alum.mit.edu> Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 07:52:08 -0000 Hi Paul, I understand what you are trying to describe but my view is that the MCU do= es not need to advertise all rooms using CLUE protocol, maybe it is also a = transport discussion but look at current multipoint solutions. The MCU offers what you call a "virtual room" that has a common mode. It do= es not offer all the participants and all potential RTP streams, it may sen= d another offer if the "virtual room" capabilities has changed. The partici= pants list and the way to ask to view a specific participant or a specific = composition is done using XCON. It already looks like we have some consensus that CLUE will not describe th= e available composition options and leave it to the MCU to decide what it w= ants to send to the participants. The selection by a participant of whom to= view or what composition to use should be part of XCON extensions.=20 I think this is the right direction since it will make the CLUE message and= transport simpler and I do not think that we should have CLUE do everythin= g if it can be done by other means. Most calls are point to point and the m= ultipoint case should not make the CLUE support more complicated. Roni Even=20 ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: Wednesday, March 07, 2012 0:30 To: Roni even Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set On 3/6/12 4:56 PM, Roni even wrote: > Hi Paul, > I think that the MCU case you described should be handled differently. In= current solutions if the MCU wants to provide information about all the me= eting participants it is done using the conferencing event package. This he= lps with addressing large messages and also work with partial notification = when a user joins or leave as specified in the XCON conference event packag= e. While I understand that the conference event package is applicable, I don't see how it is a substitute for what I described. If the MCU is the recipient of captures from multiple scenes (and it always will be), then what does it advertise? I guess there are multiple answers to that: - it can create a single scene representing a "virtual room", with a single coordinate space. It can then map all the captures onto that coordinate space. In that case it only needs one scene, for the 'main' stuff. And I guess it could do that for other purposes as well, creating one virtual scene per purpose. - it can do as I suggested, offering up each of the scenes it has received. Thus there can be several scenes for each purpose. Thanks, Paul > Roni Even > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyz= ivat [pkyzivat@alum.mit.edu] > Sent: Tuesday, March 06, 2012 22:07 > To: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: >> Hey Roni, >> >> I think this is just a vocabulary change=97multiple capture scenes are >> still allowed. The idea was that the =91purpose=92 attribute of the capt= ure >> scene would be used to differentiate them. > > A scene represents a physical (or virtually physical) space that is > represented by one or more captures. If an endpoint has available and > wants to advertise representations of more than one such space then it > will be including more than one capture scene in its advertisement. The > 'purpose' attribute won't always be sufficient to disambiguate the scenes= . > > One case where 'purpose' *would* be enough is when one scene is 'main' > representing a single room, and another is 'presentation'. > > A case where it *isn't* enough is when the endpoint is an MCU and it > wants to offer to "pass through" a scene for each connected room. In > that case, each of those scenes will probably have purpose 'main'. There > probably needs to be some other attribute that describes the scene - > perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom > Andover", ...) Or there could be a more complex attribute that describes > location. > > Thanks, > Paul > >> -Brian >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Roni Even >> *Sent:* Tuesday, March 06, 2012 12:23 AM >> *To:* 'Duckworth, Mark'; clue@ietf.org >> *Subject:* Re: [clue] Proposal to combine capture scene and capture set >> >> Hi Mark, >> >> I do not care how we call it. What I am missing is the top level. >> >> Does a provider advertise one capture scene composed of multiple capture >> scene entries. My understanding so far was that there can be more than >> one if we substitute set with scene. >> >> Can there be more than one capture scene in the advertisement in which >> case how do you differentiate between them, is there a scene identifier >> and how does the consumer know what is the scene. >> >> Roni Even >> >> *From:*clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] >> *On Behalf Of *Duckworth, Mark >> *Sent:* Monday, March 05, 2012 9:16 PM >> *To:* clue@ietf.org >> *Subject:* [clue] Proposal to combine capture scene and capture set >> >> At the interim meeting, there was some support for combining the >> concepts of =93capture scene=94 and =93capture set=94 into a single conc= ept. So >> here is a rough proposal for doing that, essentially using the term >> =93capture scene=94 to replace the previous term =93capture set=94, and >> eliminating the original separate capture scene concept. >> >> Definitions: >> >> *Capture Scene: a structure representing the scene that is captured by a >> collection of capture devices. A capture scene includes one or more >> capture scene entries, with each entry including one or more media >> captures. >> >> *Capture Scene Entry: a list of media captures of the same media type >> that together form one way to represent the capture scene. >> >> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >> >> A capture scene represents, for example, the video image of a group of >> people seated next to each other, along with the sound of their voices, >> which could be represented by some number of VCs and ACs in the capture >> scene entries. A middle box may also express capture scenes that it >> constructs from media streams it receives. >> >> A media provider arranges media captures in a capture scene to help the >> media consumer choose which captures it wants. The capture scene entries >> in a capture scene are different alternatives the provider is suggesting >> for representing the capture scene. The media consumer can choose to >> receive all media captures from one capture scene entry for each media >> type (e.g. audio and video), or it can pick and choose media captures >> regardless of how the provider arranges them in capture scene entries. >> >> A capture scene may include more than one type of media. For example, a >> capture scene can include several capture scene entries for video >> captures, and several capture scene entries for audio captures. >> >> (This text would be worked into section 6.2, not replace it completely. >> Other things in section 6.2 and elsewhere would need to be edited to be >> consistent with the new terminology in this proposal) >> >> Regards, >> >> Mark >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue= From rohanse2@cisco.com Wed Mar 7 02:13:33 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F53121F86F6 for ; Wed, 7 Mar 2012 02:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4oZmrThx8oa for ; Wed, 7 Mar 2012 02:13:32 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 27CA221F86F4 for ; Wed, 7 Mar 2012 02:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rohanse2@cisco.com; l=9076; q=dns/txt; s=iport; t=1331115205; x=1332324805; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lWGxxImTgoSwQazhJlDvwsl2mcYoYzSwVjteXBkupZ8=; b=WNVGhvYgaehnhSnw8gz7dB5Uls2QeKnjeY8w5uE3b2OGDtR+0TPM3G6d /p/tUUijj/pCqWSx4g+SlaZZCEqxqq94LFh+559YOvx8/vKvxBUX9YR7S BRejWcMbOyICjtMOeRAfrB0IUmxD5wJdY72fIYG6QZYajdU/tqSpABx+j s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABA0V0+Q/khN/2dsb2JhbABDDrUAgQeBfQEBAQMBAQEBDwEdCi4GCwUHBAIBCBEEAQEBCgYXAQYBJh8JCAIEARIIEweHYAULmwYBnx4EkA1jBKVVgiw4 X-IronPort-AV: E=Sophos;i="4.73,545,1325462400"; d="scan'208";a="67870655" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 07 Mar 2012 10:13:23 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27ADNQZ029945; Wed, 7 Mar 2012 10:13:24 GMT Received: from xmb-ams-211.cisco.com ([144.254.75.22]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 11:13:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Mar 2012 11:13:22 +0100 Message-ID: <5BDE10BA81FE9D44B1B0F706AC4985E701010B12@XMB-AMS-211.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Proposal to combine capture scene and capture set Thread-Index: AQHM+9S71unARYhJGkGydzRjRScQHpZdz08F//+EWgCAAR3XI4AAKjuQ References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com><4f55c9ba.89b90e0a.25f9.0d07@mx.google.com><4F566E6D.8050104@alum.mit.edu><4F568FFE.2020504@alum.mit.edu> From: "Robert Hansen (rohanse2)" To: "Roni even" , "Paul Kyzivat" X-OriginalArrivalTime: 07 Mar 2012 10:13:23.0970 (UTC) FILETIME=[EE1F2620:01CCFC4A] Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:13:33 -0000 To expand a bit and concur with Roni, I don't see the scenario of an MCU advertising the participants available to it as separate scenes as necessarily invalid, but it poses a number of problems. In this case the MCU would need to re-advertise its available scenes every time someone left or joined the conference - in all but small conferences these messages would rapidly become very large (as the MCU is essentially aggregating all the advertisements it has received). Further, while it gives the ability for a consumer to select exactly which participant(s) it wishes to receive, in practise endpoints generally want to receive the most 'relevant' participant(s), usually determined by something like audio activity levels; in the scenario where the consumer has to explicitly select which participants to view using CLUE I'm not sure how this could be implemented. Rob -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni even Sent: 07 March 2012 08:51 To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set Hi Paul, I understand what you are trying to describe but my view is that the MCU does not need to advertise all rooms using CLUE protocol, maybe it is also a transport discussion but look at current multipoint solutions. The MCU offers what you call a "virtual room" that has a common mode. It does not offer all the participants and all potential RTP streams, it may send another offer if the "virtual room" capabilities has changed. The participants list and the way to ask to view a specific participant or a specific composition is done using XCON. It already looks like we have some consensus that CLUE will not describe the available composition options and leave it to the MCU to decide what it wants to send to the participants. The selection by a participant of whom to view or what composition to use should be part of XCON extensions.=20 I think this is the right direction since it will make the CLUE message and transport simpler and I do not think that we should have CLUE do everything if it can be done by other means. Most calls are point to point and the multipoint case should not make the CLUE support more complicated. Roni Even=20 ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: Wednesday, March 07, 2012 0:30 To: Roni even Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set On 3/6/12 4:56 PM, Roni even wrote: > Hi Paul, > I think that the MCU case you described should be handled differently. In current solutions if the MCU wants to provide information about all the meeting participants it is done using the conferencing event package. This helps with addressing large messages and also work with partial notification when a user joins or leave as specified in the XCON conference event package. While I understand that the conference event package is applicable, I don't see how it is a substitute for what I described. If the MCU is the recipient of captures from multiple scenes (and it always will be), then what does it advertise? I guess there are multiple answers to that: - it can create a single scene representing a "virtual room", with a single coordinate space. It can then map all the captures onto that coordinate space. In that case it only needs one scene, for the 'main' stuff. And I guess it could do that for other purposes as well, creating one virtual scene per purpose. - it can do as I suggested, offering up each of the scenes it has received. Thus there can be several scenes for each purpose. Thanks, Paul > Roni Even > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Tuesday, March 06, 2012 22:07 > To: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: >> Hey Roni, >> >> I think this is just a vocabulary change-multiple capture scenes are >> still allowed. The idea was that the 'purpose' attribute of the capture >> scene would be used to differentiate them. > > A scene represents a physical (or virtually physical) space that is > represented by one or more captures. If an endpoint has available and > wants to advertise representations of more than one such space then it > will be including more than one capture scene in its advertisement. The > 'purpose' attribute won't always be sufficient to disambiguate the scenes. > > One case where 'purpose' *would* be enough is when one scene is 'main' > representing a single room, and another is 'presentation'. > > A case where it *isn't* enough is when the endpoint is an MCU and it > wants to offer to "pass through" a scene for each connected room. In > that case, each of those scenes will probably have purpose 'main'. There > probably needs to be some other attribute that describes the scene - > perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom > Andover", ...) Or there could be a more complex attribute that describes > location. > > Thanks, > Paul > >> -Brian >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Roni Even >> *Sent:* Tuesday, March 06, 2012 12:23 AM >> *To:* 'Duckworth, Mark'; clue@ietf.org >> *Subject:* Re: [clue] Proposal to combine capture scene and capture set >> >> Hi Mark, >> >> I do not care how we call it. What I am missing is the top level. >> >> Does a provider advertise one capture scene composed of multiple capture >> scene entries. My understanding so far was that there can be more than >> one if we substitute set with scene. >> >> Can there be more than one capture scene in the advertisement in which >> case how do you differentiate between them, is there a scene identifier >> and how does the consumer know what is the scene. >> >> Roni Even >> >> *From:*clue-bounces@ietf.org >> [mailto:clue-bounces@ietf.org] >> *On Behalf Of *Duckworth, Mark >> *Sent:* Monday, March 05, 2012 9:16 PM >> *To:* clue@ietf.org >> *Subject:* [clue] Proposal to combine capture scene and capture set >> >> At the interim meeting, there was some support for combining the >> concepts of "capture scene" and "capture set" into a single concept. So >> here is a rough proposal for doing that, essentially using the term >> "capture scene" to replace the previous term "capture set", and >> eliminating the original separate capture scene concept. >> >> Definitions: >> >> *Capture Scene: a structure representing the scene that is captured by a >> collection of capture devices. A capture scene includes one or more >> capture scene entries, with each entry including one or more media >> captures. >> >> *Capture Scene Entry: a list of media captures of the same media type >> that together form one way to represent the capture scene. >> >> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >> >> A capture scene represents, for example, the video image of a group of >> people seated next to each other, along with the sound of their voices, >> which could be represented by some number of VCs and ACs in the capture >> scene entries. A middle box may also express capture scenes that it >> constructs from media streams it receives. >> >> A media provider arranges media captures in a capture scene to help the >> media consumer choose which captures it wants. The capture scene entries >> in a capture scene are different alternatives the provider is suggesting >> for representing the capture scene. The media consumer can choose to >> receive all media captures from one capture scene entry for each media >> type (e.g. audio and video), or it can pick and choose media captures >> regardless of how the provider arranges them in capture scene entries. >> >> A capture scene may include more than one type of media. For example, a >> capture scene can include several capture scene entries for video >> captures, and several capture scene entries for audio captures. >> >> (This text would be worked into section 6.2, not replace it completely. >> Other things in section 6.2 and elsewhere would need to be edited to be >> consistent with the new terminology in this proposal) >> >> Regards, >> >> Mark >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Wed Mar 7 02:17:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7D21F87BE for ; Wed, 7 Mar 2012 02:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7iIc5TDvsAk for ; Wed, 7 Mar 2012 02:17:42 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by ietfa.amsl.com (Postfix) with ESMTP id 6525821F87C7 for ; Wed, 7 Mar 2012 02:17:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABU1V0920cHi/2dsb2JhbAAMNrgfAQEBBAEBAS8BBRsbChELGAkWDwkDAgECARUwEwYCAQGIDrdpBI1OgyIEpVWCdw Received: from ppp118-209-193-226.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.193.226]) by ipmail07.adl2.internode.on.net with ESMTP; 07 Mar 2012 20:47:40 +1030 Message-ID: <4F5735C0.1060705@nteczone.com> Date: Wed, 07 Mar 2012 21:17:36 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C805B@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C805B@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] switch-policy attribute proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 10:17:43 -0000 Hello Mark, Would a "site switch" policy only apply to an advertisement provided by an MCU? Regards, Christian On 6/03/2012 6:51 AM, Duckworth, Mark wrote: > > At the interim meeting I think people generally agreed the clue > framework should include a way for a provider to advertise > site-switching and segment-switching policies, and for the consumer to > request one or the other. Here is a rough proposal. > > Add a new “switch-policy” attribute for a capture scene entry (or > capture set entry, using the framework-03 terminology) (note the > attribute is for a capture scene entry not a media capture). > > Switch-policy: {site-switch, segment-switch} > > An attribute with enumerated values which identifies the policy the > provider uses for how to switch the various media captures within the > capture scene entry. > > A value of ‘site-switch’ means all the media captures within the > capture scene entry typically switch together, with the provider > attempting to include all the media captures from the same site together. > > A value of ‘segment-switch’ means the media captures in the entry > switch independently of each other, so at any point in time the media > captures could be originally sourced from different sites. > > In a provider advertisement, the provider can include multiple values > for the switch-policy attribute. The provider is saying it can provide > any one of those switch-policies it advertises. When a consumer > configures the provider, the consumer includes this attribute with > only the single value for switch-policy that it wants to receive. > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Mar 7 07:40:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D6A21E8082 for ; Wed, 7 Mar 2012 07:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLJHj0Y6JcxU for ; Wed, 7 Mar 2012 07:40:09 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id CFFDF21F85C0 for ; Wed, 7 Mar 2012 07:40:08 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id ibmG1i0091vXlb858fg9P4; Wed, 07 Mar 2012 15:40:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id ifg81i01r07duvL3dfg8Mz; Wed, 07 Mar 2012 15:40:09 +0000 Message-ID: <4F578156.3010601@alum.mit.edu> Date: Wed, 07 Mar 2012 10:40:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Robert Hansen (rohanse2)" References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com><4f55c9ba.89b90e0a.25f9.0d07@mx.google.com><4F566E6D.8050104@alum.mit.edu><4F568FFE.2020504@alum.mit.edu> <5BDE10BA81FE9D44B1B0F706AC4985E701010B12@XMB-AMS-211.cisco.com> In-Reply-To: <5BDE10BA81FE9D44B1B0F706AC4985E701010B12@XMB-AMS-211.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:40:10 -0000 Responding to both Roni and Rob: I certainly understand that not all MCUs will want to pass through all the scenes they receive. But ISTM that doing so should be possible. In any case the original question was whether an advertisement could contain more than one scene. Since all captures in a scene share a common coordinate space, it seems clear that it must be possible to have multiple scenes just to handle the captures that fall within the "room" coordinate space and those that are for presentations that don't share that same coordinate space. The only added complication for an MCU passing through scenes from multiple rooms is having a way to distinguish two scenes with the same purpose. Re the size of advertisements: as long as the clue protocol is capable of passing large messages I think we can leave this to the discretion of the MCU to decide. It can pass through or fabricate new scenes as it sees fit. I would really appreciate seeing an example of what a "virtual room" constructed by an MCU will look like. What sort of coordinate system will it use that can accommodate switched and/or mixed captures assembled from multiple rooms? Thanks, Paul On 3/7/12 5:13 AM, Robert Hansen (rohanse2) wrote: > To expand a bit and concur with Roni, I don't see the scenario of an MCU > advertising the participants available to it as separate scenes as > necessarily invalid, but it poses a number of problems. > > In this case the MCU would need to re-advertise its available scenes > every time someone left or joined the conference - in all but small > conferences these messages would rapidly become very large (as the MCU > is essentially aggregating all the advertisements it has received). > > Further, while it gives the ability for a consumer to select exactly > which participant(s) it wishes to receive, in practise endpoints > generally want to receive the most 'relevant' participant(s), usually > determined by something like audio activity levels; in the scenario > where the consumer has to explicitly select which participants to view > using CLUE I'm not sure how this could be implemented. > > Rob > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni even > Sent: 07 March 2012 08:51 > To: Paul Kyzivat > Cc: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > Hi Paul, > I understand what you are trying to describe but my view is that the MCU > does not need to advertise all rooms using CLUE protocol, maybe it is > also a transport discussion but look at current multipoint solutions. > > > The MCU offers what you call a "virtual room" that has a common mode. It > does not offer all the participants and all potential RTP streams, it > may send another offer if the "virtual room" capabilities has changed. > The participants list and the way to ask to view a specific participant > or a specific composition is done using XCON. > > It already looks like we have some consensus that CLUE will not describe > the available composition options and leave it to the MCU to decide what > it wants to send to the participants. The selection by a participant of > whom to view or what composition to use should be part of XCON > extensions. > > I think this is the right direction since it will make the CLUE message > and transport simpler and I do not think that we should have CLUE do > everything if it can be done by other means. Most calls are point to > point and the multipoint case should not make the CLUE support more > complicated. > > Roni Even > > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Wednesday, March 07, 2012 0:30 > To: Roni even > Cc: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > On 3/6/12 4:56 PM, Roni even wrote: >> Hi Paul, >> I think that the MCU case you described should be handled differently. > In current solutions if the MCU wants to provide information about all > the meeting participants it is done using the conferencing event > package. This helps with addressing large messages and also work with > partial notification when a user joins or leave as specified in the XCON > conference event package. > > While I understand that the conference event package is applicable, I > don't see how it is a substitute for what I described. > > If the MCU is the recipient of captures from multiple scenes (and it > always will be), then what does it advertise? I guess there are multiple > answers to that: > > - it can create a single scene representing a "virtual room", with a > single coordinate space. It can then map all the captures onto that > coordinate space. In that case it only needs one scene, for the 'main' > stuff. And I guess it could do that for other purposes as well, creating > one virtual scene per purpose. > > - it can do as I suggested, offering up each of the scenes it has > received. Thus there can be several scenes for each purpose. > > Thanks, > Paul > >> Roni Even >> >> ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul > Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Tuesday, March 06, 2012 22:07 >> To: clue@ietf.org >> Subject: Re: [clue] Proposal to combine capture scene and capture set >> >> On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: >>> Hey Roni, >>> >>> I think this is just a vocabulary change-multiple capture scenes are >>> still allowed. The idea was that the 'purpose' attribute of the > capture >>> scene would be used to differentiate them. >> >> A scene represents a physical (or virtually physical) space that is >> represented by one or more captures. If an endpoint has available and >> wants to advertise representations of more than one such space then it >> will be including more than one capture scene in its advertisement. > The >> 'purpose' attribute won't always be sufficient to disambiguate the > scenes. >> >> One case where 'purpose' *would* be enough is when one scene is 'main' >> representing a single room, and another is 'presentation'. >> >> A case where it *isn't* enough is when the endpoint is an MCU and it >> wants to offer to "pass through" a scene for each connected room. In >> that case, each of those scenes will probably have purpose 'main'. > There >> probably needs to be some other attribute that describes the scene - >> perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom >> Andover", ...) Or there could be a more complex attribute that > describes >> location. >> >> Thanks, >> Paul >> >>> -Brian >>> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf >>> Of *Roni Even >>> *Sent:* Tuesday, March 06, 2012 12:23 AM >>> *To:* 'Duckworth, Mark'; clue@ietf.org >>> *Subject:* Re: [clue] Proposal to combine capture scene and capture > set >>> >>> Hi Mark, >>> >>> I do not care how we call it. What I am missing is the top level. >>> >>> Does a provider advertise one capture scene composed of multiple > capture >>> scene entries. My understanding so far was that there can be more > than >>> one if we substitute set with scene. >>> >>> Can there be more than one capture scene in the advertisement in > which >>> case how do you differentiate between them, is there a scene > identifier >>> and how does the consumer know what is the scene. >>> >>> Roni Even >>> >>> *From:*clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] >>> *On Behalf Of *Duckworth, Mark >>> *Sent:* Monday, March 05, 2012 9:16 PM >>> *To:* clue@ietf.org >>> *Subject:* [clue] Proposal to combine capture scene and capture set >>> >>> At the interim meeting, there was some support for combining the >>> concepts of "capture scene" and "capture set" into a single concept. > So >>> here is a rough proposal for doing that, essentially using the term >>> "capture scene" to replace the previous term "capture set", and >>> eliminating the original separate capture scene concept. >>> >>> Definitions: >>> >>> *Capture Scene: a structure representing the scene that is captured > by a >>> collection of capture devices. A capture scene includes one or more >>> capture scene entries, with each entry including one or more media >>> captures. >>> >>> *Capture Scene Entry: a list of media captures of the same media type >>> that together form one way to represent the capture scene. >>> >>> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >>> >>> A capture scene represents, for example, the video image of a group > of >>> people seated next to each other, along with the sound of their > voices, >>> which could be represented by some number of VCs and ACs in the > capture >>> scene entries. A middle box may also express capture scenes that it >>> constructs from media streams it receives. >>> >>> A media provider arranges media captures in a capture scene to help > the >>> media consumer choose which captures it wants. The capture scene > entries >>> in a capture scene are different alternatives the provider is > suggesting >>> for representing the capture scene. The media consumer can choose to >>> receive all media captures from one capture scene entry for each > media >>> type (e.g. audio and video), or it can pick and choose media captures >>> regardless of how the provider arranges them in capture scene > entries. >>> >>> A capture scene may include more than one type of media. For example, > a >>> capture scene can include several capture scene entries for video >>> captures, and several capture scene entries for audio captures. >>> >>> (This text would be worked into section 6.2, not replace it > completely. >>> Other things in section 6.2 and elsewhere would need to be edited to > be >>> consistent with the new terminology in this proposal) >>> >>> Regards, >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Wed Mar 7 12:03:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F7A11E809A for ; Wed, 7 Mar 2012 12:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr5qGsAcbkes for ; Wed, 7 Mar 2012 12:03:18 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC8411E8098 for ; Wed, 7 Mar 2012 12:03:18 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 7 Mar 2012 12:03:17 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 7 Mar 2012 12:03:16 -0800 Thread-Topic: [clue] switch-policy attribute proposal Thread-Index: Acz8S4zJBx9LkUcbTAuPJ2vUGZarogAUEb1w Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB790678@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C805B@CRPMBOXPRD01.polycom.com> <4F5735C0.1060705@nteczone.com> In-Reply-To: <4F5735C0.1060705@nteczone.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: [clue] switch-policy attribute proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:03:20 -0000 Hi Christian, In practice that might be the way it works out, but I don't see a reason to= restrict it in the document. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Wednesday, March 07, 2012 5:18 AM > To: clue@ietf.org > Subject: Re: [clue] switch-policy attribute proposal >=20 > Hello Mark, >=20 > Would a "site switch" policy only apply to an advertisement provided by a= n > MCU? >=20 > Regards, Christian >=20 > On 6/03/2012 6:51 AM, Duckworth, Mark wrote: > > > > At the interim meeting I think people generally agreed the clue > > framework should include a way for a provider to advertise > > site-switching and segment-switching policies, and for the consumer to > > request one or the other. Here is a rough proposal. > > > > Add a new "switch-policy" attribute for a capture scene entry (or > > capture set entry, using the framework-03 terminology) (note the > > attribute is for a capture scene entry not a media capture). > > > > Switch-policy: {site-switch, segment-switch} > > > > An attribute with enumerated values which identifies the policy the > > provider uses for how to switch the various media captures within the > > capture scene entry. > > > > A value of 'site-switch' means all the media captures within the > > capture scene entry typically switch together, with the provider > > attempting to include all the media captures from the same site togethe= r. > > > > A value of 'segment-switch' means the media captures in the entry > > switch independently of each other, so at any point in time the media > > captures could be originally sourced from different sites. > > > > In a provider advertisement, the provider can include multiple values > > for the switch-policy attribute. The provider is saying it can provide > > any one of those switch-policies it advertises. When a consumer > > configures the provider, the consumer includes this attribute with > > only the single value for switch-policy that it wants to receive. > > > > Regards, > > > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Mar 7 12:03:21 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB1311E8098 for ; Wed, 7 Mar 2012 12:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HupyUlsJglN for ; Wed, 7 Mar 2012 12:03:18 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9111E8097 for ; Wed, 7 Mar 2012 12:03:17 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 7 Mar 2012 12:03:16 -0800 From: "Duckworth, Mark" To: "Brian Baldino (bbaldino)" , Roni Even , "clue@ietf.org" Date: Wed, 7 Mar 2012 12:03:15 -0800 Thread-Topic: [clue] differentiating between multiple capture scenes - was Proposal to combine capture scene and capture set Thread-Index: Acz8m8vSC0tmalzATjqmymE1CRTNdA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB790677@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790677CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] differentiating between multiple capture scenes - was Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:03:21 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790677CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes multiple capture scenes are allowed in a single provider advertisement. Brian - there is no 'purpose' attribute on a capture scene. The purpose at= tribute is on media captures. I'm not sure a purpose attribute makes sense= on a scene, we would have to think about it. It could conflict with the a= ttribute on media captures. Are you proposing something new? Roni - about differentiating between capture scenes - what information do y= ou propose to use to differentiate them? My view is they are differentiate= d by the media captures (described by attributes) that are contained in the= capture scene entries, and that is all we need. If you think there needs = to be more information, what do you propose? Mark From: Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] Sent: Tuesday, March 06, 2012 5:11 AM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Proposal to combine capture scene and capture set Hey Roni, I think this is just a vocabulary change-multiple capture scenes are still = allowed. The idea was that the 'purpose' attribute of the capture scene wo= uld be used to differentiate them. -Brian From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Tuesday, March 06, 2012 12:23 AM To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set Hi Mark, I do not care how we call it. What I am missing is the top level. Does a provider advertise one capture scene composed of multiple capture sc= ene entries. My understanding so far was that there can be more than one i= f we substitute set with scene. Can there be more than one capture scene in the advertisement in which case= how do you differentiate between them, is there a scene identifier and how= does the consumer know what is the scene. Roni Even From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth= , Mark Sent: Monday, March 05, 2012 9:16 PM To: clue@ietf.org Subject: [clue] Proposal to combine capture scene and capture set At the interim meeting, there was some support for combining the concepts o= f "capture scene" and "capture set" into a single concept. So here is a ro= ugh proposal for doing that, essentially using the term "capture scene" to = replace the previous term "capture set", and eliminating the original separ= ate capture scene concept. Definitions: *Capture Scene: a structure representing the scene that is captured by a co= llection of capture devices. A capture scene includes one or more capture = scene entries, with each entry including one or more media captures. *Capture Scene Entry: a list of media captures of the same media type that = together form one way to represent the capture scene. Text for section 6.2 Capture Scene (was 6.2 Capture Set): A capture scene represents, for example, the video image of a group of peop= le seated next to each other, along with the sound of their voices, which c= ould be represented by some number of VCs and ACs in the capture scene entr= ies. A middle box may also express capture scenes that it constructs from m= edia streams it receives. A media provider arranges media captures in a capture scene to help the med= ia consumer choose which captures it wants. The capture scene entries in a= capture scene are different alternatives the provider is suggesting for re= presenting the capture scene. The media consumer can choose to receive all= media captures from one capture scene entry for each media type (e.g. audi= o and video), or it can pick and choose media captures regardless of how th= e provider arranges them in capture scene entries. A capture scene may include more than one type of media. For example, a ca= pture scene can include several capture scene entries for video captures, a= nd several capture scene entries for audio captures. (This text would be worked into section 6.2, not replace it completely. Ot= her things in section 6.2 and elsewhere would need to be edited to be consi= stent with the new terminology in this proposal) Regards, Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790677CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes multiple capture scenes are allowed in a single provider = advertisement.

 

Brian – there is no ‘purpose’ attribute o= n a capture scene.  The purpose attribute is on media captures.  = I’m not sure a purpose attribute makes sense on a scene, we would hav= e to think about it.  It could conflict with the attribute on media ca= ptures.  Are you proposing something new?

 

Roni – about differen= tiating between capture scenes – what information do you propose to u= se to differentiate them?  My view is they are differentiated by the m= edia captures (described by attributes) that are contained in the capture s= cene entries, and that is all we need.  If you think there needs to be= more information, what do you propose?

 

Mark

 

From: Brian Baldino (bbaldino) [mailt= o:bbaldino@cisco.com]
Sent: Tuesday, March 06, 2012 5:11 AM
<= b>To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] Proposal to combine capture scene and capture set<= /p>

 

Hey Roni,

I think this is just a v= ocabulary change—multiple capture scenes are still allowed.  The= idea was that the ‘purpose’ attribute of the capture scene wou= ld be used to differentiate them.

<= o:p> 

-Brian

=

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behal= f Of Roni Even
Sent: Tuesday, March 06, 2012 12:23 AM
T= o: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Propo= sal to combine capture scene and capture set

 

Hi Mark,

I do not care how we call it. What I am missing = is the top level.

Does a provider advertise one capture scene composed of mult= iple capture scene entries. My understanding so far was that there can be&n= bsp; more than one if we substitute set with scene.

Can there be more than one= capture scene in the advertisement in which case how do you differentiate = between them, is there a scene identifier and how does the consumer know wh= at is the scene.

Roni Even

 

From: clue-bounces@i= etf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: M= onday, March 05, 2012 9:16 PM
To: clue@ietf.org
Subject: [clue] Proposal to combine capture s= cene and capture set

=  

At the interim meeting, there was= some support for combining the concepts of “capture scene” and= “capture set” into a single concept.  So here is a rough = proposal for doing that, essentially using the term “capture scene= 221; to replace the previous term “capture set”, and eliminatin= g the original separate capture scene concept.

 

Definitions:

 

*Capture Sc= ene: a structure representing the scene that is captured by a collection of= capture devices.  A capture scene includes one or more capture scene = entries, with each entry including one or more media captures.  <= /o:p>

 

*Ca= pture Scene Entry: a list of media captures of the same media type that tog= ether form one way to represent the capture scene.

 

Text for section 6.2= Capture Scene (was 6.2 Capture Set):

 

A capture scene represents, for exa= mple, the video image of a group of people seated next to each other, along= with the sound of their voices, which could be represented by some number = of VCs and ACs in the capture scene entries. A middle box may also express = capture scenes that it constructs from media streams it receives.

 

A media= provider arranges media captures in a capture scene to help the media cons= umer choose which captures it wants.  The capture scene entries in a c= apture scene are different alternatives the provider is suggesting for repr= esenting the capture scene.  The media consumer can choose to receive = all media captures from one capture scene entry for each media type (e.g. a= udio and video), or it can pick and choose media captures regardless of how= the provider arranges them in capture scene entries.

 

A capture scene may= include more than one type of media.  For example, a capture scene ca= n include several capture scene entries for video captures, and several cap= ture scene entries for audio captures. 

 

(This text would be worked = into section 6.2, not replace it completely.  Other things in section = 6.2 and elsewhere would need to be edited to be consistent with the new ter= minology in this proposal)

 

Regards,

Ma= rk

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790677CRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Wed Mar 7 12:50:39 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B052D11E80AE for ; Wed, 7 Mar 2012 12:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoTkgIGlDqHZ for ; Wed, 7 Mar 2012 12:50:38 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6875411E80A1 for ; Wed, 7 Mar 2012 12:50:38 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id ihpX1i0031wpRvQ54kqe5p; Wed, 07 Mar 2012 20:50:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id ikqe1i02007duvL3ekqe3i; Wed, 07 Mar 2012 20:50:38 +0000 Message-ID: <4F57CA1D.9000409@alum.mit.edu> Date: Wed, 07 Mar 2012 15:50:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB790677@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB790677@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] differentiating between multiple capture scenes - was Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:50:39 -0000 On 3/7/12 3:03 PM, Duckworth, Mark wrote: > Yes multiple capture scenes are allowed in a single provider advertisement. > > Brian – there is no ‘purpose’ attribute on a capture scene. The purpose > attribute is on media captures. I’m not sure a purpose attribute makes > sense on a scene, we would have to think about it. It could conflict > with the attribute on media captures. Are you proposing something new? Hmm. I had fallen into that trap. > Roni – about differentiating between capture scenes – what information > do you propose to use to differentiate them? My view is they are > differentiated by the media captures (described by attributes) that are > contained in the capture scene entries, and that is all we need. If you > think there needs to be more information, what do you propose? I think the problem is that when you have captures from multiple scenes there don't seem to be enough attributes to make sense of what you have. One or more attributes on the scene could help with that. Within a scene you can understand the captures by purpose and area of capture. But once you have more than one scene that isn't sufficient. The reason is that area of capture is based on the coordinate space for the scene, and two scenes are unrelated. So, if I have captures of purpose 'main' from both scene-1 and scene-2, I have no basis to decide which of them I want. Some useful attributes on the scene would help. Just something like a description of what/where the scene is. E.g. scene-1 is Cisco-SJ and scene-2 is Polycom-Andover. It might also be useful to know when multiple scenes are sourced by the same endpoint. E.g. that a scene containing captures from cameras (e.g. purpose=main) came from he same endpoint as the scene containing a capture with purpose=presentation. While these come from the same endpoint, they may need to be separate scenes because they have differing coordinate spaces. Thanks, Paul > Mark > > *From:*Brian Baldino (bbaldino) [mailto:bbaldino@cisco.com] > *Sent:* Tuesday, March 06, 2012 5:11 AM > *To:* Roni Even; Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Proposal to combine capture scene and capture set > > Hey Roni, > > I think this is just a vocabulary change—multiple capture scenes are > still allowed. The idea was that the ‘purpose’ attribute of the capture > scene would be used to differentiate them. > > -Brian > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Roni Even > *Sent:* Tuesday, March 06, 2012 12:23 AM > *To:* 'Duckworth, Mark'; clue@ietf.org > *Subject:* Re: [clue] Proposal to combine capture scene and capture set > > Hi Mark, > > I do not care how we call it. What I am missing is the top level. > > Does a provider advertise one capture scene composed of multiple capture > scene entries. My understanding so far was that there can be more than > one if we substitute set with scene. > > Can there be more than one capture scene in the advertisement in which > case how do you differentiate between them, is there a scene identifier > and how does the consumer know what is the scene. > > Roni Even > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] > *On Behalf Of *Duckworth, Mark > *Sent:* Monday, March 05, 2012 9:16 PM > *To:* clue@ietf.org > *Subject:* [clue] Proposal to combine capture scene and capture set > > At the interim meeting, there was some support for combining the > concepts of “capture scene” and “capture set” into a single concept. So > here is a rough proposal for doing that, essentially using the term > “capture scene” to replace the previous term “capture set”, and > eliminating the original separate capture scene concept. > > Definitions: > > *Capture Scene: a structure representing the scene that is captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. > > *Capture Scene Entry: a list of media captures of the same media type > that together form one way to represent the capture scene. > > Text for section 6.2 Capture Scene (was 6.2 Capture Set): > > A capture scene represents, for example, the video image of a group of > people seated next to each other, along with the sound of their voices, > which could be represented by some number of VCs and ACs in the capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives. > > A media provider arranges media captures in a capture scene to help the > media consumer choose which captures it wants. The capture scene entries > in a capture scene are different alternatives the provider is suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each media > type (e.g. audio and video), or it can pick and choose media captures > regardless of how the provider arranges them in capture scene entries. > > A capture scene may include more than one type of media. For example, a > capture scene can include several capture scene entries for video > captures, and several capture scene entries for audio captures. > > (This text would be worked into section 6.2, not replace it completely. > Other things in section 6.2 and elsewhere would need to be edited to be > consistent with the new terminology in this proposal) > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Wed Mar 7 16:15:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5611E808C for ; Wed, 7 Mar 2012 16:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.29 X-Spam-Level: X-Spam-Status: No, score=-106.29 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPoFRqXTz14K for ; Wed, 7 Mar 2012 16:15:22 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 71B2511E8072 for ; Wed, 7 Mar 2012 16:15:22 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J005ASI1KI9@szxga05-in.huawei.com> for clue@ietf.org; Thu, 08 Mar 2012 08:15:20 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00JFDI1K9Z@szxga05-in.huawei.com> for clue@ietf.org; Thu, 08 Mar 2012 08:15:20 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHQ95056; Thu, 08 Mar 2012 08:15:19 +0800 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 08:15:10 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 08:15:13 +0800 Date: Thu, 08 Mar 2012 00:15:14 +0000 From: Roni even In-reply-to: <4F578156.3010601@alum.mit.edu> X-Originating-IP: [172.24.1.46] To: Paul Kyzivat , "Robert Hansen (rohanse2)" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: [clue] Proposal to combine capture scene and capture set Thread-index: AQHM+9S71unARYhJGkGydzRjRScQHpZdz08F//+EWgCAAR3XI4AAKjuQ///XogCAAREbTA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> <4F566E6D.8050104@alum.mit.edu> <4F568FFE.2020504@alum.mit.edu> <5BDE10BA81FE9D44B1B0F706AC4985E701010B12@XMB-AMS-211.cisco.com> <4F578156.3010601@alum.mit.edu> Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 00:15:24 -0000 Hi Paul, First having just the CLUE information from multi[le sites is not enough since you need the full offer (SDP) to send and receive the media and if not going through the MCU you may need to use ICE to establish the connection As for the virtual room. We have two use cases For Segment switch the co-ordinate are constructed by the MCU and have no scale For Site switch it will need to send the co-ordinates of the room that he is now sending. This can be done as a message when switching or a better way it can be available as roster information using the conference event package which is updated when a user joins or drops. Note that the XCON event package supports partial notifications Roni ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: Wednesday, March 07, 2012 17:40 To: Robert Hansen (rohanse2) Cc: Roni even; clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set Responding to both Roni and Rob: I certainly understand that not all MCUs will want to pass through all the scenes they receive. But ISTM that doing so should be possible. In any case the original question was whether an advertisement could contain more than one scene. Since all captures in a scene share a common coordinate space, it seems clear that it must be possible to have multiple scenes just to handle the captures that fall within the "room" coordinate space and those that are for presentations that don't share that same coordinate space. The only added complication for an MCU passing through scenes from multiple rooms is having a way to distinguish two scenes with the same purpose. Re the size of advertisements: as long as the clue protocol is capable of passing large messages I think we can leave this to the discretion of the MCU to decide. It can pass through or fabricate new scenes as it sees fit. I would really appreciate seeing an example of what a "virtual room" constructed by an MCU will look like. What sort of coordinate system will it use that can accommodate switched and/or mixed captures assembled from multiple rooms? Thanks, Paul On 3/7/12 5:13 AM, Robert Hansen (rohanse2) wrote: > To expand a bit and concur with Roni, I don't see the scenario of an MCU > advertising the participants available to it as separate scenes as > necessarily invalid, but it poses a number of problems. > > In this case the MCU would need to re-advertise its available scenes > every time someone left or joined the conference - in all but small > conferences these messages would rapidly become very large (as the MCU > is essentially aggregating all the advertisements it has received). > > Further, while it gives the ability for a consumer to select exactly > which participant(s) it wishes to receive, in practise endpoints > generally want to receive the most 'relevant' participant(s), usually > determined by something like audio activity levels; in the scenario > where the consumer has to explicitly select which participants to view > using CLUE I'm not sure how this could be implemented. > > Rob > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni even > Sent: 07 March 2012 08:51 > To: Paul Kyzivat > Cc: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > Hi Paul, > I understand what you are trying to describe but my view is that the MCU > does not need to advertise all rooms using CLUE protocol, maybe it is > also a transport discussion but look at current multipoint solutions. > > > The MCU offers what you call a "virtual room" that has a common mode. It > does not offer all the participants and all potential RTP streams, it > may send another offer if the "virtual room" capabilities has changed. > The participants list and the way to ask to view a specific participant > or a specific composition is done using XCON. > > It already looks like we have some consensus that CLUE will not describe > the available composition options and leave it to the MCU to decide what > it wants to send to the participants. The selection by a participant of > whom to view or what composition to use should be part of XCON > extensions. > > I think this is the right direction since it will make the CLUE message > and transport simpler and I do not think that we should have CLUE do > everything if it can be done by other means. Most calls are point to > point and the multipoint case should not make the CLUE support more > complicated. > > Roni Even > > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Wednesday, March 07, 2012 0:30 > To: Roni even > Cc: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > On 3/6/12 4:56 PM, Roni even wrote: >> Hi Paul, >> I think that the MCU case you described should be handled differently. > In current solutions if the MCU wants to provide information about all > the meeting participants it is done using the conferencing event > package. This helps with addressing large messages and also work with > partial notification when a user joins or leave as specified in the XCON > conference event package. > > While I understand that the conference event package is applicable, I > don't see how it is a substitute for what I described. > > If the MCU is the recipient of captures from multiple scenes (and it > always will be), then what does it advertise? I guess there are multiple > answers to that: > > - it can create a single scene representing a "virtual room", with a > single coordinate space. It can then map all the captures onto that > coordinate space. In that case it only needs one scene, for the 'main' > stuff. And I guess it could do that for other purposes as well, creating > one virtual scene per purpose. > > - it can do as I suggested, offering up each of the scenes it has > received. Thus there can be several scenes for each purpose. > > Thanks, > Paul > >> Roni Even >> >> ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul > Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Tuesday, March 06, 2012 22:07 >> To: clue@ietf.org >> Subject: Re: [clue] Proposal to combine capture scene and capture set >> >> On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: >>> Hey Roni, >>> >>> I think this is just a vocabulary change-multiple capture scenes are >>> still allowed. The idea was that the 'purpose' attribute of the > capture >>> scene would be used to differentiate them. >> >> A scene represents a physical (or virtually physical) space that is >> represented by one or more captures. If an endpoint has available and >> wants to advertise representations of more than one such space then it >> will be including more than one capture scene in its advertisement. > The >> 'purpose' attribute won't always be sufficient to disambiguate the > scenes. >> >> One case where 'purpose' *would* be enough is when one scene is 'main' >> representing a single room, and another is 'presentation'. >> >> A case where it *isn't* enough is when the endpoint is an MCU and it >> wants to offer to "pass through" a scene for each connected room. In >> that case, each of those scenes will probably have purpose 'main'. > There >> probably needs to be some other attribute that describes the scene - >> perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom >> Andover", ...) Or there could be a more complex attribute that > describes >> location. >> >> Thanks, >> Paul >> >>> -Brian >>> >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > Behalf >>> Of *Roni Even >>> *Sent:* Tuesday, March 06, 2012 12:23 AM >>> *To:* 'Duckworth, Mark'; clue@ietf.org >>> *Subject:* Re: [clue] Proposal to combine capture scene and capture > set >>> >>> Hi Mark, >>> >>> I do not care how we call it. What I am missing is the top level. >>> >>> Does a provider advertise one capture scene composed of multiple > capture >>> scene entries. My understanding so far was that there can be more > than >>> one if we substitute set with scene. >>> >>> Can there be more than one capture scene in the advertisement in > which >>> case how do you differentiate between them, is there a scene > identifier >>> and how does the consumer know what is the scene. >>> >>> Roni Even >>> >>> *From:*clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] >>> *On Behalf Of *Duckworth, Mark >>> *Sent:* Monday, March 05, 2012 9:16 PM >>> *To:* clue@ietf.org >>> *Subject:* [clue] Proposal to combine capture scene and capture set >>> >>> At the interim meeting, there was some support for combining the >>> concepts of "capture scene" and "capture set" into a single concept. > So >>> here is a rough proposal for doing that, essentially using the term >>> "capture scene" to replace the previous term "capture set", and >>> eliminating the original separate capture scene concept. >>> >>> Definitions: >>> >>> *Capture Scene: a structure representing the scene that is captured > by a >>> collection of capture devices. A capture scene includes one or more >>> capture scene entries, with each entry including one or more media >>> captures. >>> >>> *Capture Scene Entry: a list of media captures of the same media type >>> that together form one way to represent the capture scene. >>> >>> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >>> >>> A capture scene represents, for example, the video image of a group > of >>> people seated next to each other, along with the sound of their > voices, >>> which could be represented by some number of VCs and ACs in the > capture >>> scene entries. A middle box may also express capture scenes that it >>> constructs from media streams it receives. >>> >>> A media provider arranges media captures in a capture scene to help > the >>> media consumer choose which captures it wants. The capture scene > entries >>> in a capture scene are different alternatives the provider is > suggesting >>> for representing the capture scene. The media consumer can choose to >>> receive all media captures from one capture scene entry for each > media >>> type (e.g. audio and video), or it can pick and choose media captures >>> regardless of how the provider arranges them in capture scene > entries. >>> >>> A capture scene may include more than one type of media. For example, > a >>> capture scene can include several capture scene entries for video >>> captures, and several capture scene entries for audio captures. >>> >>> (This text would be worked into section 6.2, not replace it > completely. >>> Other things in section 6.2 and elsewhere would need to be edited to > be >>> consistent with the new terminology in this proposal) >>> >>> Regards, >>> >>> Mark >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From bo.burman@ericsson.com Thu Mar 8 05:01:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413421F866D for ; Thu, 8 Mar 2012 05:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSq-GrPdf4hz for ; Thu, 8 Mar 2012 05:01:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3A51421F86A2 for ; Thu, 8 Mar 2012 05:01:06 -0800 (PST) X-AuditID: c1b4fb3d-b7c6fae0000045c0-fb-4f58ad915a5f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.3B.17856.19DA85F4; Thu, 8 Mar 2012 14:01:05 +0100 (CET) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.209]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 8 Mar 2012 14:01:04 +0100 From: Bo Burman To: "clue@ietf.org" Date: Thu, 8 Mar 2012 14:01:03 +0100 Thread-Topic: New draft on controlling codec parameters; draft-westerlund-avtext-codec-operation-point-00 Thread-Index: Acz9K4SvuUC29E4dSl6CitiVHixBSA== Message-ID: <05F760EF51FA6A4F804F9759C239313A3A72087208@ESESSCMS0361.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_05F760EF51FA6A4F804F9759C239313A3A72087208ESESSCMS0361e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] New draft on controlling codec parameters; draft-westerlund-avtext-codec-operation-point-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "avtext@ietf.org" List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:01:07 -0000 --_000_05F760EF51FA6A4F804F9759C239313A3A72087208ESESSCMS0361e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, My colleagues and I have a proposal for an RTCP extension to AVPF CCM allow= ing a media receiver to dynamically ask the media sender to use a certain c= odec configuration (called a Codec Operation Point, COP). We see this as be= ing used both in WEBRTC (RTCWEB WG) and Video Conferencing / Telepresence (= CLUE WG). Additional applications are expected. The proposal is not intended to replace or conflict with codec negotiation = taking place during SDP Offer / Answer, but rather optimize and fine-tune c= odec usage within the limits established by SDP O/A. The draft defines a set of what is believed generally useful and reasonably= codec-independent set of parameters. Those parameters can be used by a med= ia sender to describe the codec configuration (Codec Operation Point) used = to generate the media stream to the media receiver. The media receiver can = in turn examine the parameter values in the announced Codec Operation Point= and use the same set of defined parameters to ask the media sender to use = other, more suitable values for those parameters. It is the media sender's = responsibility to decide if such request can be honored or not. If the requ= est is accepted, the media sender then changes the media stream accordingly= and sends another Codec Operation Point announcement with the changed para= meter values. One possible example is to let a video media receiver control the encoded v= ideo resolution based on decoded video window display size. https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-po= int/ This draft is designed to: * Allow for minimal implementation. The media sender need only announce COP= support for the payload types it wishes to make controllable. It is not a = requirement to support all parameter types, and receive support for each pa= rameter type is signaled explicitly in SDP. Unsupported parameter types can= safely be ignored. * Be extensible. It is for example easy to define more parameter types in e= xtensions to this draft. New message types and result codes can also be def= ined as extensions. * Be possible to use both in point-to-point, in multipoint (conferencing), = and even some specific multicast situations. * Be responsive. The user at the media receiver can request and experience = the result of changes in a dynamic and interactive fashion. The codec contr= ol signaling need only traverse the media path and uses the most responsive= RTCP mode available, AVPF. * Support single layer as well as multi-layered (scalable) media streams. A= multi-layered media stream can easily be described and configured by using= multiple, simultaneously active Codec Operation Points. * Be as media and codec agnostic as possible. The defined parameter types a= re chosen to be as generic as possible and should therefore apply to many d= ifferent codecs. Some media type awareness is however included in the chose= n set of parameters. * Be robust. It leaves to the media sender to decide exactly what is change= d. A media sender that receives a request to set a certain value for a para= meter can choose another value that is seen as more appropriate, or even ch= oose to not change anything at all. "Unreasonable" requests can thus safely= be ignored. * Be flexible in what type of parameter value restrictions that can be desc= ribed. A request can use either an exact single value, an open-ended minimu= m or maximum restriction, or a range of values. It is also possible to use = a "target" value, standalone or in combination with a range, to express a p= reference. It is even possible to specify a set of prioritized, alternative= configurations that the media sender can choose from. * Allow for advertised, synchronized configuration changes. The Codec Opera= tion Point notification can be time stamped some time into the future, allo= wing the media receiver some time for informed preparation (if needed) befo= re the actual media stream change occurs. We would like to see this work as WG item in AVTEXT WG. If you have input, please provide comments to the AVTEXT WG (reply-to set t= here). Best Regards Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- --_000_05F760EF51FA6A4F804F9759C239313A3A72087208ESESSCMS0361e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
My colleagues and I have a proposal for an RTCP extension to AVPF CCM = allowing a media receiver to dynamically ask the media sender to use a cert= ain codec configuration (called a Codec Operation Point, COP). We see this = as being used both in WEBRTC (RTCWEB WG) and Video Conferencing / Telepresence (CLUE WG). Additional application= s are expected.
 
The proposal is not intended to replace or conflict with codec negotia= tion taking place during SDP Offer / Answer, but rather optimize and fine-t= une codec usage within the limits established by SDP O/A.
 
The draft defines a set of what is believed generally useful and reaso= nably codec-independent set of parameters. Those parameters can be used by = a media sender to describe the codec configuration (Codec Operation Point) = used to generate the media stream to the media receiver. The media receiver can in turn examine the parameter= values in the announced Codec Operation Point and use the same set of defi= ned parameters to ask the media sender to use other, more suitable values f= or those parameters. It is the media sender's responsibility to decide if such request can be honored or not. If= the request is accepted, the media sender then changes the media stream ac= cordingly and sends another Codec Operation Point announcement with the cha= nged parameter values.
 
One possible example is to let a video media receiver control the enco= ded video resolution based on decoded video window display size.
 
 
This draft is designed to:
 
* Allow for minimal implementation. The media sender need only announc= e COP support for the payload types it wishes to make controllable. It is n= ot a requirement to support all parameter types, and receive support for ea= ch parameter type is signaled explicitly in SDP. Unsupported parameter types can safely be ignored.
 
* Be extensible. It is for example easy to define more parameter types= in extensions to this draft. New message types and result codes can also b= e defined as extensions.
 
* Be possible to use both in point-to-point, in multipoint (conferenci= ng), and even some specific multicast situations.
 
* Be responsive. The user at the media receiver can request and experi= ence the result of changes in a dynamic and interactive fashion. The codec = control signaling need only traverse the media path and uses the most respo= nsive RTCP mode available, AVPF.
 
* Support single layer as well as multi-layered (scalable) media strea= ms. A multi-layered media stream can easily be described and configured by = using multiple, simultaneously active Codec Operation Points.
 
* Be as media and codec agnostic as possible. The defined parameter ty= pes are chosen to be as generic as possible and should therefore apply to m= any different codecs. Some media type awareness is however included in the = chosen set of parameters.
 
* Be robust. It leaves to the media sender to decide exactly what is c= hanged. A media sender that receives a request to set a certain value for a= parameter can choose another value that is seen as more appropriate, or ev= en choose to not change anything at all. "Unreasonable" requests can thus safely be ignored.
 
* Be flexible in what type of parameter value restrictions that can be= described. A request can use either an exact single value, an open-ended m= inimum or maximum restriction, or a range of values. It is also possible to= use a "target" value, standalone or in combination with a range, to express a preference. It is even possibl= e to specify a set of prioritized, alternative configurations that the medi= a sender can choose from.
 
* Allow for advertised, synchronized configuration changes. The Codec = Operation Point notification can be time stamped some time into the future,= allowing the media receiver some time for informed preparation (if needed)= before the actual media stream change occurs.
 
We would like to see this work as WG item in AVTEXT WG.
 
If you have input, please provide comments to the AVTEXT WG (reply-to = set there).
 
Best Regards
 
Bo Burman
 
----------------------------------------------------------------------=
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------=
Ericsson AB          = ;       | Phone  +46 10 7141311
F=E4r=F6gatan 6         &= nbsp;       | Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com
----------------------------------------------------------------------=
 
 
 --_000_05F760EF51FA6A4F804F9759C239313A3A72087208ESESSCMS0361e_-- From Mark.Duckworth@polycom.com Thu Mar 8 12:58:52 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0E221E8018 for ; Thu, 8 Mar 2012 12:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdriI7BHDmXb for ; Thu, 8 Mar 2012 12:58:45 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9760B21F8639 for ; Thu, 8 Mar 2012 12:58:26 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 8 Mar 2012 12:58:25 -0800 From: "Duckworth, Mark" To: Michael Hammer Date: Thu, 8 Mar 2012 12:58:22 -0800 Thread-Topic: [clue] Proposal to combine capture scene and capture set Thread-Index: Acz7VbjnD62laL3TRVeU36ualqDptwCF9LrA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB790BAF@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790BAFCRPMBOXPRD01p_" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:58:52 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790BAFCRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, I don't think anybody responded to this specifically. I put some comments = below. Mark From: Michael Hammer [mailto:mphmmr@gmail.com] Sent: Monday, March 05, 2012 11:58 PM To: Duckworth, Mark Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set Mark, Not sure if I am getting this properly. There seems to be only a couple co= ncepts. Let me feed back to you in my terms and see if I am missing some key point. An atomic level (no lower subcomponents) media capture can be either a vide= o capture (VC) or an audio capture (AC). [Duckworth, Mark] correct. A capture scene is an aggregation with structural meta-data that includes: - zero or more AC, or (logical meaning also "and") - zero or more VC, or [Duckworth, Mark] Yes it includes other media captures (not restricted to a= udio and video). But these other media captures are grouped into "capture = scene entries". So the hierarchy is: A provider advertisement includes cap= ture scenes. A capture scene includes capture scene entries. A capture sc= ene entry includes media captures. - zero or more capture scenes, i.e. it aggregates iteratively. [Duckworth, Mark] No, not iterative. The capture scene can be constructed by either the media provider or the me= dia consumer. [Duckworth, Mark] No, the media provider constructs capture scenes, which i= t includes in the provider advertisement it sends to the consumer. That last point seems to be implied by "provider arranges" and "consumer ca= n choose" but would be good to verify. [Duckworth, Mark] The consumer can choose from among various things the pro= vider advertises, but the consumer does not construct a capture scene out o= f this. I would think that what the sender does prior or what the receiver does sub= sequent to receipt might be secondary. Miss anything? Mike On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark > wrote: At the interim meeting, there was some support for combining the concepts o= f "capture scene" and "capture set" into a single concept. So here is a ro= ugh proposal for doing that, essentially using the term "capture scene" to = replace the previous term "capture set", and eliminating the original separ= ate capture scene concept. Definitions: *Capture Scene: a structure representing the scene that is captured by a co= llection of capture devices. A capture scene includes one or more capture = scene entries, with each entry including one or more media captures. *Capture Scene Entry: a list of media captures of the same media type that = together form one way to represent the capture scene. Text for section 6.2 Capture Scene (was 6.2 Capture Set): A capture scene represents, for example, the video image of a group of peop= le seated next to each other, along with the sound of their voices, which c= ould be represented by some number of VCs and ACs in the capture scene entr= ies. A middle box may also express capture scenes that it constructs from m= edia streams it receives. A media provider arranges media captures in a capture scene to help the med= ia consumer choose which captures it wants. The capture scene entries in a= capture scene are different alternatives the provider is suggesting for re= presenting the capture scene. The media consumer can choose to receive all= media captures from one capture scene entry for each media type (e.g. audi= o and video), or it can pick and choose media captures regardless of how th= e provider arranges them in capture scene entries. A capture scene may include more than one type of media. For example, a ca= pture scene can include several capture scene entries for video captures, a= nd several capture scene entries for audio captures. (This text would be worked into section 6.2, not replace it completely. Ot= her things in section 6.2 and elsewhere would need to be edited to be consi= stent with the new terminology in this proposal) Regards, Mark _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790BAFCRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike,<= o:p>

 

I don’t think anybody responded to this= specifically.  I put some comments below.

 

Mark

 <= /span>

From: Michael Hammer [ma= ilto:mphmmr@gmail.com]
Sent: Monday, March 05, 2012 11:58 PM
= To: Duckworth, Mark
Cc: clue@ietf.org
Subject: R= e: [clue] Proposal to combine capture scene and capture set

 

Mark,

 

Not sure if I am getting this properly.  = ;There seems to be only a couple concepts.

Let me feed back to you in my terms and see if I am missing s= ome key point.

 

An atomic level (no lower subcompone= nts) media capture can be either a video capture (VC) or an audio capture (= AC).

[Duckworth, Mark] corr= ect.

 

A capture scene is an aggreg= ation with structural meta-data that includes:

- zero or more AC, or (logical meaning also "and&quo= t;)

- zero or more VC, or

[Duckworth, Mark] Yes it inclu= des other media captures (not restricted to audio and video).  But the= se other media captures are grouped into “capture scene entries”= ;.  So the hierarchy is: A provider advertisement includes capture sce= nes.  A capture scene includes capture scene entries.  A capture = scene entry includes media captures.

 

- zero or more capture scenes, i.e. it aggregates iteratively.

[Duckworth, Mark] No, not iterativ= e.

 

The capture scene can be const= ructed by either the media provider or the media consumer.

[Duckworth, Mark] No, the media provider co= nstructs capture scenes, which it includes in the provider advertisement it= sends to the consumer.

 

That last point seems to be implied by "provider arranges" and = "consumer can choose" but would be good to verify.

=

[Duckworth, Mark] The consumer can choose= from among various things the provider advertises, but the consumer does n= ot construct a capture scene out of this.

 

I would think that what the sender does prior or what the receiver= does subsequent to receipt might be secondary.

 

Mis= s anything?

Mike

 

 

On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark <Mark.Duckworth@pol= ycom.com> wrote:

At the interim meet= ing, there was some support for combining the concepts of “capture sc= ene” and “capture set” into a single concept.  So he= re is a rough proposal for doing that, essentially using the term “ca= pture scene” to replace the previous term “capture set”, = and eliminating the original separate capture scene concept.

=

 

Definitions:

 =

*Capture Scene: a structure representing the scene th= at is captured by a collection of capture devices.  A capture scene in= cludes one or more capture scene entries, with each entry including one or = more media captures. 

 

*Capture Scene Entry: a list of media captures of the same media type tha= t together form one way to represent the capture scene.

 

Text for section 6.2 Capture Scene (was 6.2 C= apture Set):

 

A capture sce= ne represents, for example, the video image of a group of people seated nex= t to each other, along with the sound of their voices, which could be repre= sented by some number of VCs and ACs in the capture scene entries. A middle= box may also express capture scenes that it constructs from media streams = it receives.

 

A media provi= der arranges media captures in a capture scene to help the media consumer c= hoose which captures it wants.  The capture scene entries in a capture= scene are different alternatives the provider is suggesting for representi= ng the capture scene.  The media consumer can choose to receive all me= dia captures from one capture scene entry for each media type (e.g. audio a= nd video), or it can pick and choose media captures regardless of how the p= rovider arranges them in capture scene entries.

 =

A capture scene may include more than one type of med= ia.  For example, a capture scene can include several capture scene en= tries for video captures, and several capture scene entries for audio captu= res. 

 

(This text wou= ld be worked into section 6.2, not replace it completely.  Other thing= s in section 6.2 and elsewhere would need to be edited to be consistent wit= h the new terminology in this proposal)

 

Regards,

Mark

=


___________________= ____________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailma= n/listinfo/clue

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FB790BAFCRPMBOXPRD01p_-- From mphmmr@gmail.com Thu Mar 8 14:06:51 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A8721E802D for ; Thu, 8 Mar 2012 14:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3HUYMZZIFdU for ; Thu, 8 Mar 2012 14:06:49 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC3121E8028 for ; Thu, 8 Mar 2012 14:06:48 -0800 (PST) Received: by lagj5 with SMTP id j5so1187971lag.31 for ; Thu, 08 Mar 2012 14:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ypOPBz+bqjBnmiIcM5tGAr+C+/5BbI0xucrhCkMaw38=; b=m8ht4+Y+dr7So11Fp263jc2LXX3dW0fDDSwjm0dt+KmgLfDAkRGFWUp+10hrXf/oQm BsXdxswGhLbGnLiyfOOuJfv0H75L1vv6tDPReiG0YRWc0SoEvtJMi2X+EfGscSydCHAO QRnnwpt4pSypMd+MuFU1KK4URlXeT9AZoYy8KbUrAU9BXpV1afMyOm5iGzVNw/0+J5XN jvxO1nmegabPumE5bqIlDabevNjUFTXy55AKQP7NT09HgL8F1a5JGOPX+yVY+Kchmq2/ ok8VHCX36XxW+XkISHBru4LSV1S/y1Yg/VrVXEA5YKwTG6viGS7xhvz6ERq0dHSuNpY+ RS8g== MIME-Version: 1.0 Received: by 10.152.132.104 with SMTP id ot8mr5811724lab.17.1331244407477; Thu, 08 Mar 2012 14:06:47 -0800 (PST) Received: by 10.112.9.166 with HTTP; Thu, 8 Mar 2012 14:06:46 -0800 (PST) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB790BAF@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB790BAF@CRPMBOXPRD01.polycom.com> Date: Thu, 8 Mar 2012 17:06:46 -0500 Message-ID: From: Michael Hammer To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=f46d0433a09404546104bac27e5d Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:06:51 -0000 --f46d0433a09404546104bac27e5d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks. That makes it much clearer for me. Mike On Thu, Mar 8, 2012 at 3:58 PM, Duckworth, Mark wrote: > Hi Mike,**** > > ** ** > > I don=92t think anybody responded to this specifically. I put some comme= nts > below.**** > > ** ** > > Mark**** > > ** ** > > *From:* Michael Hammer [mailto:mphmmr@gmail.com] > *Sent:* Monday, March 05, 2012 11:58 PM > *To:* Duckworth, Mark > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Proposal to combine capture scene and capture set**= * > * > > ** ** > > Mark,**** > > ** ** > > Not sure if I am getting this properly. There seems to be only a couple > concepts.**** > > Let me feed back to you in my terms and see if I am missing some key poin= t. > **** > > ** ** > > An atomic level (no lower subcomponents) media capture can be either a > video capture (VC) or an audio capture (AC).**** > > *[Duckworth, Mark] correct.* > > ** ** > > A capture scene is an aggregation with structural meta-data that includes= : > **** > > - zero or more AC, or (logical meaning also "and")**** > > - zero or more VC, or**** > > *[Duckworth, Mark] Yes it includes other media captures (not restricted > to audio and video). But these other media captures are grouped into > =93capture scene entries=94. So the hierarchy is: A provider advertiseme= nt > includes capture scenes. A capture scene includes capture scene entries. > A capture scene entry includes media captures.* > > ** ** > > - zero or more capture scenes, i.e. it aggregates iteratively.**** > > *[Duckworth, Mark] No, not iterative.* > > ** ** > > The capture scene can be constructed by either the media provider or the > media consumer.**** > > *[Duckworth, Mark] No, the media provider constructs capture scenes, > which it includes in the provider advertisement it sends to the consumer.= * > **** > > ** ** > > That last point seems to be implied by "provider arranges" and "consumer > can choose" but would be good to verify.**** > > *[Duckworth, Mark] The consumer can choose from among various things the > provider advertises, but the consumer does not construct a capture scene > out of this.* > > ** ** > > I would think that what the sender does prior or what the receiver does > subsequent to receipt might be secondary.**** > > ** ** > > Miss anything?**** > > Mike**** > > ** ** > > ** ** > > On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, Mark < > Mark.Duckworth@polycom.com> wrote:**** > > At the interim meeting, there was some support for combining the concepts > of =93capture scene=94 and =93capture set=94 into a single concept. So h= ere is a > rough proposal for doing that, essentially using the term =93capture scen= e=94 > to replace the previous term =93capture set=94, and eliminating the origi= nal > separate capture scene concept.**** > > **** > > Definitions:**** > > **** > > *Capture Scene: a structure representing the scene that is captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. **** > > **** > > *Capture Scene Entry: a list of media captures of the same media type tha= t > together form one way to represent the capture scene.**** > > **** > > Text for section 6.2 Capture Scene (was 6.2 Capture Set):**** > > **** > > A capture scene represents, for example, the video image of a group of > people seated next to each other, along with the sound of their voices, > which could be represented by some number of VCs and ACs in the capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives.**** > > **** > > A media provider arranges media captures in a capture scene to help the > media consumer choose which captures it wants. The capture scene entries > in a capture scene are different alternatives the provider is suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each media ty= pe > (e.g. audio and video), or it can pick and choose media captures regardle= ss > of how the provider arranges them in capture scene entries.**** > > **** > > A capture scene may include more than one type of media. For example, a > capture scene can include several capture scene entries for video capture= s, > and several capture scene entries for audio captures. **** > > **** > > (This text would be worked into section 6.2, not replace it completely. > Other things in section 6.2 and elsewhere would need to be edited to be > consistent with the new terminology in this proposal)**** > > **** > > Regards,**** > > Mark**** > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --f46d0433a09404546104bac27e5d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks.=A0 That makes it much clearer for me.
=A0
= Mike


=A0
On Thu, Mar 8, 2= 012 at 3:58 PM, Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:
Hi Mike,

=A0

I don=92t think anyb= ody responded to this specifically.=A0 I put some comments below.=

=A0

Mark<= u>

=A0

From: Michae= l Hammer [mailto:mphm= mr@gmail.com]
Sent: Monday, March 05, 2012 11:58 PM
To: Duckworth, Mark<= br>Cc: clue@ietf.= org
Subject: Re: [clue] Proposal to combine capture scene and= capture set

=A0

Mark,

=A0

Not sure if I am getting this properly. = =A0There seems to be only a couple concepts.

Let me feed back to you in my terms and s= ee if I am missing some key point.

=A0

An atomic= level (no lower subcomponents) media capture can be either a video capture= (VC) or an audio capture (AC).

[Duckworth, Ma= rk] correct.

=A0

A capture scene is an aggregation with st= ructural meta-data that includes:

- zero or more AC, or (logical meaning also "and")

- zero or more VC, or

[Duckworth, Mark= ] Yes it includes other media captures (not restricted to audio and video).= =A0 But these other media captures are grouped into =93capture scene entrie= s=94.=A0 So the hierarchy is: A provider advertisement includes capture sce= nes.=A0 A capture scene includes capture scene entries.=A0 A capture scene = entry includes media captures.

=A0

- zero or more capture scenes, i.= e. it aggregates iteratively.

[Duckworth, Ma= rk] No, not iterative.

=A0

The capture scene can be constructed by either the media= provider or the media consumer.

[Duckworth, Ma= rk] No, the media provider constructs capture scenes, which it includes in = the provider advertisement it sends to the consumer.

=A0

That last point seems to be implied by "provider arrang= es" and "consumer can choose" but would be good to verify.

[Duckworth, Ma= rk] The consumer can choose from among various things the provider advertis= es, but the consumer does not construct a capture scene out of this.=

=A0

I would think that what the sende= r does prior or what the receiver does subsequent to receipt might be secon= dary.

=A0

Miss anything?

Mike

=A0=

=A0<= /p>

On Mon, Mar 5, 2012 at 2:16 PM, Duckworth, M= ark <Mar= k.Duckworth@polycom.com> wrote:

At the interim meeting, there was some sup= port for combining the concepts of =93capture scene=94 and =93capture set= =94 into a single concept.=A0 So here is a rough proposal for doing that, e= ssentially using the term =93capture scene=94 to replace the previous term = =93capture set=94, and eliminating the original separate capture scene conc= ept.

=A0

Definiti= ons:

=A0

*Capture Scene: a structure representing the scene that is c= aptured by a collection of capture devices.=A0 A capture scene includes one= or more capture scene entries, with each entry including one or more media= captures.=A0

=A0

*Capture= Scene Entry: a list of media captures of the same media type that together= form one way to represent the capture scene.

=A0

Text for section 6.2 Capture Sc= ene (was 6.2 Capture Set):

=A0

A capture scene represents, for example= , the video image of a group of people seated next to each other, along wit= h the sound of their voices, which could be represented by some number of V= Cs and ACs in the capture scene entries. A middle box may also express capt= ure scenes that it constructs from media streams it receives.=

=A0

A media = provider arranges media captures in a capture scene to help the media consu= mer choose which captures it wants.=A0 The capture scene entries in a captu= re scene are different alternatives the provider is suggesting for represen= ting the capture scene.=A0 The media consumer can choose to receive all med= ia captures from one capture scene entry for each media type (e.g. audio an= d video), or it can pick and choose media captures regardless of how the pr= ovider arranges them in capture scene entries.

=A0

A captur= e scene may include more than one type of media.=A0 For example, a capture = scene can include several capture scene entries for video captures, and sev= eral capture scene entries for audio captures.=A0

=A0

(This te= xt would be worked into section 6.2, not replace it completely.=A0 Other th= ings in section 6.2 and elsewhere would need to be edited to be consistent = with the new terminology in this proposal)

=A0

Regards,=

Mark

=


___________________= ____________________________
clue mailing list
clu= e@ietf.org
https://www.ietf.org/mailman/listinfo/clue

=A0

<= /blockquote>

--f46d0433a09404546104bac27e5d-- From pkyzivat@alum.mit.edu Fri Mar 9 09:10:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3B721F8697 for ; Fri, 9 Mar 2012 09:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNvlmqW8V8I9 for ; Fri, 9 Mar 2012 09:10:18 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB0221F8694 for ; Fri, 9 Mar 2012 09:10:16 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by QMTA11.westchester.pa.mail.comcast.net with comcast id jT5Q1i0091ZXKqc5BVAHvP; Fri, 09 Mar 2012 17:10:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id jVAH1i00F07duvL3hVAHV0; Fri, 09 Mar 2012 17:10:17 +0000 Message-ID: <4F5A3977.5040906@alum.mit.edu> Date: Fri, 09 Mar 2012 12:10:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Roni even References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4f55c9ba.89b90e0a.25f9.0d07@mx.google.com> <4F566E6D.8050104@alum.mit.edu> <4F568FFE.2020504@alum.mit.edu> <5BDE10BA81FE9D44B1B0F706AC4985E701010B12@XMB-AMS-211.cisco.com> <4F578156.3010601@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:10:19 -0000 On 3/7/12 7:15 PM, Roni even wrote: > Hi Paul, > First having just the CLUE information from multi[le sites is not enough since you need the full offer (SDP) to send and receive the media and if not going through the MCU you may need to use ICE to establish the connection You need the SDP for those streams you select, but not for those you don't select. If your point is about the size of the SDP, its possible that the SDP could be reasonably small even for many selected captures. > As for the virtual room. We have two use cases > For Segment switch the co-ordinate are constructed by the MCU and have no scale I suppose that works if all the advertised captures in the scene are segment switched. > For Site switch it will need to send the co-ordinates of the room that he is now sending. This can be done as a message when switching or a better way it can be available as roster information using the conference event package which is updated when a user joins or drops. Note that the XCON event package supports partial notifications That seems to require some machinery that hasn't yet been discussed. It seems to trash the notion of having a single coordinate system per scene, unless "site switching" is really "scene switching" (which it may well be), and there is some way to define a scene as containing other scenes. This "message when switching" - you mean within the clue protocol? Like a new advertisement? But if it was an advertisement, then it would require a new selection, ... and wouldn't be very timely. If it were to work that way then ISTM that it would need to be some other sort of message, as yet not investigated. What about *mixed* captures, where the input to the mix is captures from other scenes? ISTM that these use cases need to be worked out in considerably more detail to identify exactly what machinery is needed to represent them. Thanks, Paul > Roni > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Wednesday, March 07, 2012 17:40 > To: Robert Hansen (rohanse2) > Cc: Roni even; clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set > > Responding to both Roni and Rob: > > I certainly understand that not all MCUs will want to pass through all > the scenes they receive. But ISTM that doing so should be possible. > > In any case the original question was whether an advertisement could > contain more than one scene. Since all captures in a scene share a > common coordinate space, it seems clear that it must be possible to have > multiple scenes just to handle the captures that fall within the "room" > coordinate space and those that are for presentations that don't share > that same coordinate space. > > The only added complication for an MCU passing through scenes from > multiple rooms is having a way to distinguish two scenes with the same > purpose. > > Re the size of advertisements: as long as the clue protocol is capable > of passing large messages I think we can leave this to the discretion of > the MCU to decide. It can pass through or fabricate new scenes as it > sees fit. > > I would really appreciate seeing an example of what a "virtual room" > constructed by an MCU will look like. What sort of coordinate system > will it use that can accommodate switched and/or mixed captures > assembled from multiple rooms? > > Thanks, > Paul > > On 3/7/12 5:13 AM, Robert Hansen (rohanse2) wrote: >> To expand a bit and concur with Roni, I don't see the scenario of an MCU >> advertising the participants available to it as separate scenes as >> necessarily invalid, but it poses a number of problems. >> >> In this case the MCU would need to re-advertise its available scenes >> every time someone left or joined the conference - in all but small >> conferences these messages would rapidly become very large (as the MCU >> is essentially aggregating all the advertisements it has received). >> >> Further, while it gives the ability for a consumer to select exactly >> which participant(s) it wishes to receive, in practise endpoints >> generally want to receive the most 'relevant' participant(s), usually >> determined by something like audio activity levels; in the scenario >> where the consumer has to explicitly select which participants to view >> using CLUE I'm not sure how this could be implemented. >> >> Rob >> >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Roni even >> Sent: 07 March 2012 08:51 >> To: Paul Kyzivat >> Cc: clue@ietf.org >> Subject: Re: [clue] Proposal to combine capture scene and capture set >> >> Hi Paul, >> I understand what you are trying to describe but my view is that the MCU >> does not need to advertise all rooms using CLUE protocol, maybe it is >> also a transport discussion but look at current multipoint solutions. >> >> >> The MCU offers what you call a "virtual room" that has a common mode. It >> does not offer all the participants and all potential RTP streams, it >> may send another offer if the "virtual room" capabilities has changed. >> The participants list and the way to ask to view a specific participant >> or a specific composition is done using XCON. >> >> It already looks like we have some consensus that CLUE will not describe >> the available composition options and leave it to the MCU to decide what >> it wants to send to the participants. The selection by a participant of >> whom to view or what composition to use should be part of XCON >> extensions. >> >> I think this is the right direction since it will make the CLUE message >> and transport simpler and I do not think that we should have CLUE do >> everything if it can be done by other means. Most calls are point to >> point and the multipoint case should not make the CLUE support more >> complicated. >> >> Roni Even >> >> ________________________________________ >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Wednesday, March 07, 2012 0:30 >> To: Roni even >> Cc: clue@ietf.org >> Subject: Re: [clue] Proposal to combine capture scene and capture set >> >> On 3/6/12 4:56 PM, Roni even wrote: >>> Hi Paul, >>> I think that the MCU case you described should be handled differently. >> In current solutions if the MCU wants to provide information about all >> the meeting participants it is done using the conferencing event >> package. This helps with addressing large messages and also work with >> partial notification when a user joins or leave as specified in the XCON >> conference event package. >> >> While I understand that the conference event package is applicable, I >> don't see how it is a substitute for what I described. >> >> If the MCU is the recipient of captures from multiple scenes (and it >> always will be), then what does it advertise? I guess there are multiple >> answers to that: >> >> - it can create a single scene representing a "virtual room", with a >> single coordinate space. It can then map all the captures onto that >> coordinate space. In that case it only needs one scene, for the 'main' >> stuff. And I guess it could do that for other purposes as well, creating >> one virtual scene per purpose. >> >> - it can do as I suggested, offering up each of the scenes it has >> received. Thus there can be several scenes for each purpose. >> >> Thanks, >> Paul >> >>> Roni Even >>> >>> ________________________________________ >>> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul >> Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: Tuesday, March 06, 2012 22:07 >>> To: clue@ietf.org >>> Subject: Re: [clue] Proposal to combine capture scene and capture set >>> >>> On 3/6/12 5:10 AM, Brian Baldino (bbaldino) wrote: >>>> Hey Roni, >>>> >>>> I think this is just a vocabulary change-multiple capture scenes are >>>> still allowed. The idea was that the 'purpose' attribute of the >> capture >>>> scene would be used to differentiate them. >>> >>> A scene represents a physical (or virtually physical) space that is >>> represented by one or more captures. If an endpoint has available and >>> wants to advertise representations of more than one such space then it >>> will be including more than one capture scene in its advertisement. >> The >>> 'purpose' attribute won't always be sufficient to disambiguate the >> scenes. >>> >>> One case where 'purpose' *would* be enough is when one scene is 'main' >>> representing a single room, and another is 'presentation'. >>> >>> A case where it *isn't* enough is when the endpoint is an MCU and it >>> wants to offer to "pass through" a scene for each connected room. In >>> that case, each of those scenes will probably have purpose 'main'. >> There >>> probably needs to be some other attribute that describes the scene - >>> perhaps just a text string. (E.g. "Cisco SJ", "Cisco BXB", Polycom >>> Andover", ...) Or there could be a more complex attribute that >> describes >>> location. >>> >>> Thanks, >>> Paul >>> >>>> -Brian >>>> >>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On >> Behalf >>>> Of *Roni Even >>>> *Sent:* Tuesday, March 06, 2012 12:23 AM >>>> *To:* 'Duckworth, Mark'; clue@ietf.org >>>> *Subject:* Re: [clue] Proposal to combine capture scene and capture >> set >>>> >>>> Hi Mark, >>>> >>>> I do not care how we call it. What I am missing is the top level. >>>> >>>> Does a provider advertise one capture scene composed of multiple >> capture >>>> scene entries. My understanding so far was that there can be more >> than >>>> one if we substitute set with scene. >>>> >>>> Can there be more than one capture scene in the advertisement in >> which >>>> case how do you differentiate between them, is there a scene >> identifier >>>> and how does the consumer know what is the scene. >>>> >>>> Roni Even >>>> >>>> *From:*clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] >>>> *On Behalf Of *Duckworth, Mark >>>> *Sent:* Monday, March 05, 2012 9:16 PM >>>> *To:* clue@ietf.org >>>> *Subject:* [clue] Proposal to combine capture scene and capture set >>>> >>>> At the interim meeting, there was some support for combining the >>>> concepts of "capture scene" and "capture set" into a single concept. >> So >>>> here is a rough proposal for doing that, essentially using the term >>>> "capture scene" to replace the previous term "capture set", and >>>> eliminating the original separate capture scene concept. >>>> >>>> Definitions: >>>> >>>> *Capture Scene: a structure representing the scene that is captured >> by a >>>> collection of capture devices. A capture scene includes one or more >>>> capture scene entries, with each entry including one or more media >>>> captures. >>>> >>>> *Capture Scene Entry: a list of media captures of the same media type >>>> that together form one way to represent the capture scene. >>>> >>>> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >>>> >>>> A capture scene represents, for example, the video image of a group >> of >>>> people seated next to each other, along with the sound of their >> voices, >>>> which could be represented by some number of VCs and ACs in the >> capture >>>> scene entries. A middle box may also express capture scenes that it >>>> constructs from media streams it receives. >>>> >>>> A media provider arranges media captures in a capture scene to help >> the >>>> media consumer choose which captures it wants. The capture scene >> entries >>>> in a capture scene are different alternatives the provider is >> suggesting >>>> for representing the capture scene. The media consumer can choose to >>>> receive all media captures from one capture scene entry for each >> media >>>> type (e.g. audio and video), or it can pick and choose media captures >>>> regardless of how the provider arranges them in capture scene >> entries. >>>> >>>> A capture scene may include more than one type of media. For example, >> a >>>> capture scene can include several capture scene entries for video >>>> captures, and several capture scene entries for audio captures. >>>> >>>> (This text would be worked into section 6.2, not replace it >> completely. >>>> Other things in section 6.2 and elsewhere would need to be edited to >> be >>>> consistent with the new terminology in this proposal) >>>> >>>> Regards, >>>> >>>> Mark >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > From mary.ietf.barnes@gmail.com Fri Mar 9 13:21:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC73E21F85EA for ; Fri, 9 Mar 2012 13:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxOvGjPUqd35 for ; Fri, 9 Mar 2012 13:21:37 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5521F85EE for ; Fri, 9 Mar 2012 13:21:36 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2088366vcb.31 for ; Fri, 09 Mar 2012 13:21:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7tbRVT22DYvWyROZepYNY/VIQOec/HO5cvDwkutM5uk=; b=H1ehSIWoFCkxGZhqVXFUeW/owsqY7E0U0prLLF3521KYQRHxT6tm01czFJDd3IG9H7 uEa18ItMwQ9+k7eaFRAc6czJVm7tHQspBjlGlbIdojPSW2gSnFZJBrxpDMEJar1NPyAq FunMKlXOZws0cmt8d+chFcF2R/Lu3fo7bI0E7c5RYq6vYv8aSV+g44jLgpF7Uf272nng TjyUlfVMVyHJEC6HeE5XqGAfn40GXSeQ1820EByvI1wtJI7Nc3mN5y1tShPgFro/ACVz qsXqx3u/b1kKTvIB9EJTGE4ZOMYDZGLcX0/d5iKY/pQHmKVN9OxWWTrr8N4xPH9xqkKw R2HA== MIME-Version: 1.0 Received: by 10.52.88.103 with SMTP id bf7mr6236442vdb.72.1331328096109; Fri, 09 Mar 2012 13:21:36 -0800 (PST) Received: by 10.52.111.136 with HTTP; Fri, 9 Mar 2012 13:21:36 -0800 (PST) In-Reply-To: <4F567412.7090506@alum.mit.edu> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> Date: Fri, 9 Mar 2012 15:21:36 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf307f3c043f83a204bad5fad4 Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:21:38 -0000 --20cf307f3c043f83a204bad5fad4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul, I'm trying to discern if we have consensus on the basic question of whether people are okay with replacing the term "capture set" with "capture scene" using the definitions that Mark has below. Paul, can you please clarify two things for the WG: 1) That you are speaking as an individual in the threads (i.e., you are not trying to evaluate the thread for consensus) 2) I *think* you are disagreeing with Mark's proposal, but that's not clear to me. I think you are suggesting that "Capture Scene" be defined to have a more information than just capture scene entries. Is that correct? Thanks, Mary. - as WG co-chair On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat wrote: > On 3/5/12 2:16 PM, Duckworth, Mark wrote: > >> At the interim meeting, there was some support for combining the >> concepts of =93capture scene=94 and =93capture set=94 into a single conc= ept. So >> here is a rough proposal for doing that, essentially using the term >> =93capture scene=94 to replace the previous term =93capture set=94, and >> eliminating the original separate capture scene concept. >> >> Definitions: >> >> *Capture Scene: a structure representing the scene that is captured by a >> collection of capture devices. A capture scene includes one or more >> capture scene entries, with each entry including one or more media >> captures. >> >> *Capture Scene Entry: a list of media captures of the same media type >> that together form one way to represent the capture scene. >> > > One of the reasons I preferred "Capture Scene" to "Capture Set" is that > "set" implied to me that it is *only* a set of captures. But in fact ther= e > are already other attributes in addition to the set of captures (such as > the purpose), and there will probably be more as we proceed. > > To me, "Capture Scene Entry" conveys some of that same assumption. Namely= , > that a Capture Scene" is made up of a number of Capture Scene Entries, > which seems to exclude other attributes that are not Capture Scene Entrie= s. > > It would feel more natural to me to have a Capture Set that is a set of > media captures. (That is, what was previously called a Capture Set Entry.= ) > And then define another term for a grouping of these Capture Sets. I'm > having trouble coming up with a term for that which matches the intent > well, but as a swag, how about Capture Set Alternatives. > > So then you would have a logical structure something like: > > - Advertisement > - Capture Scene (one or more) > - Description > - Purpose > - Area of Scene > - Capture Set Alternatives (one or more) > - Capture Set (one or more) > - Capture > > I don't think Capture Set Alternatives is the right term. I think I am > hampered in finding a better term by not really having a crisp > understanding of the reason for having this grouping. Its partly about > alternatives in that there is an expectation that for a particular medium > you would choose only one. But its not about alternatives in that you nee= d > to choose audio and video independently. Also, that is only an > approximation - there seem to be expected cases when entries from more th= an > one video entry would be chosen. > > In my experience, when its hard to find a good term it usually means that > the thing being named is not sufficiently defined and likely can be > factored into more meaningful pieces. > > Thanks, > Paul > > Text for section 6.2 Capture Scene (was 6.2 Capture Set): >> >> A capture scene represents, for example, the video image of a group of >> people seated next to each other, along with the sound of their voices, >> which could be represented by some number of VCs and ACs in the capture >> scene entries. A middle box may also express capture scenes that it >> constructs from media streams it receives. >> >> A media provider arranges media captures in a capture scene to help the >> media consumer choose which captures it wants. The capture scene entries >> in a capture scene are different alternatives the provider is suggesting >> for representing the capture scene. The media consumer can choose to >> receive all media captures from one capture scene entry for each media >> type (e.g. audio and video), or it can pick and choose media captures >> regardless of how the provider arranges them in capture scene entries. >> >> A capture scene may include more than one type of media. For example, a >> capture scene can include several capture scene entries for video >> captures, and several capture scene entries for audio captures. >> >> (This text would be worked into section 6.2, not replace it completely. >> Other things in section 6.2 and elsewhere would need to be edited to be >> consistent with the new terminology in this proposal) >> >> Regards, >> >> Mark >> >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --20cf307f3c043f83a204bad5fad4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Paul,

I'm trying to discern if we have consens= us on the basic question of whether people are okay with replacing the term= "capture set" with "capture scene" using the definitio= ns that Mark has below. =A0 =A0Paul, can you please clarify two things for = the WG:
1) That you are speaking as an individual in the threads (i.e., you are not= trying to evaluate the thread for consensus)
2) =A0I *think* you= are disagreeing with Mark's proposal, but that's not clear to me. = =A0I think you are suggesting that "Capture Scene" be defined to = have a more information than just capture scene entries. =A0Is that correct= ?

Thanks,
Mary.
- as WG co-chair
<= br>
On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat = <pkyzivat@alu= m.mit.edu> wrote:
On 3/5/12 2:16 PM, Duckwor= th, Mark wrote:
At the interim meeting, there was some support for combining the
concepts of =93capture scene=94 and =93capture set=94 into a single concept= . So
here is a rough proposal for doing that, essentially using the term
=93capture scene=94 to replace the previous term =93capture set=94, and
eliminating the original separate capture scene concept.

Definitions:

*Capture Scene: a structure representing the scene that is captured by a collection of capture devices. A capture scene includes one or more
capture scene entries, with each entry including one or more media
captures.

*Capture Scene Entry: a list of media captures of the same media type
that together form one way to represent the capture scene.

One of the reasons I preferred "Capture Scene" to "Capture S= et" is that "set" implied to me that it is *only* a set of c= aptures. But in fact there are already other attributes in addition to the = set of captures (such as the purpose), and there will probably be more as w= e proceed.

To me, "Capture Scene Entry" conveys some of that same assumption= . Namely, that a Capture Scene" is made up of a number of Capture Scen= e Entries, which seems to exclude other attributes that are not Capture Sce= ne Entries.

It would feel more natural to me to have a Capture Set that is a set of med= ia captures. (That is, what was previously called a Capture Set Entry.) And= then define another term for a grouping of these Capture Sets. I'm hav= ing trouble coming up with a term for that which matches the intent well, b= ut as a swag, how about Capture Set Alternatives.

So then you would have a logical structure something like:

- Advertisement
=A0- Capture Scene (one or more)
=A0 =A0- Description
=A0 =A0- Purpose
=A0 =A0- Area of Scene
=A0 =A0- Capture Set Alternatives (one or more)
=A0 =A0 =A0- Capture Set (one or more)
=A0 =A0 =A0 =A0- Capture

I don't think Capture Set Alternatives is the right term. I think I am = hampered in finding a better term by not really having a crisp understandin= g of the reason for having this grouping. Its partly about alternatives in = that there is an expectation that for a particular medium you would choose = only one. But its not about alternatives in that you need to choose audio a= nd video independently. Also, that is only an approximation - there seem to= be expected cases when entries from more than one video entry would be cho= sen.

In my experience, when its hard to find a good term it usually means that t= he thing being named is not sufficiently defined and likely can be factored= into more meaningful pieces.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

Text for section 6.2 Capture Scene (was 6.2 Capture Set):

A capture scene represents, for example, the video image of a group of
people seated next to each other, along with the sound of their voices,
which could be represented by some number of VCs and ACs in the capture
scene entries. A middle box may also express capture scenes that it
constructs from media streams it receives.

A media provider arranges media captures in a capture scene to help the
media consumer choose which captures it wants. The capture scene entries in a capture scene are different alternatives the provider is suggesting for representing the capture scene. The media consumer can choose to
receive all media captures from one capture scene entry for each media
type (e.g. audio and video), or it can pick and choose media captures
regardless of how the provider arranges them in capture scene entries.

A capture scene may include more than one type of media. For example, a
capture scene can include several capture scene entries for video
captures, and several capture scene entries for audio captures.

(This text would be worked into section 6.2, not replace it completely.
Other things in section 6.2 and elsewhere would need to be edited to be
consistent with the new terminology in this proposal)

Regards,

Mark



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307f3c043f83a204bad5fad4-- From mary.ietf.barnes@gmail.com Fri Mar 9 13:43:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4097D21F85B6 for ; Fri, 9 Mar 2012 13:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.526 X-Spam-Level: X-Spam-Status: No, score=-103.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykUuOjs1IhhN for ; Fri, 9 Mar 2012 13:43:55 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8E21F85AF for ; Fri, 9 Mar 2012 13:43:55 -0800 (PST) Received: by ggmi1 with SMTP id i1so1344918ggm.31 for ; Fri, 09 Mar 2012 13:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=hhJSHKPtNNYczfJ7dmctK8dzXFj7054WHB1xE2HiRX0=; b=JgKrCp6pUnJRSFxhFmwFZn5w2glZUrK27GNU1fW7vIsRox8XQAM27nT4qP+/ZE3hK4 g2sTlkuDPDU8YV8l88DtB1gyNnEKE+pb39osEeMEcOhF4ELqjqzxL/aedPaniS4ZmCWa 5SxGjsp+QfHJwZkcXjXCXyXbn7bnNlEyahlUS1SskNcex+FinIXsaWog/UU3LXGmL6zb ymyxhGGYOoEA1f6pKkgH4Pm/9QQH/WHD+gO/drgXjQcnw9i+n3DBg0knQxjUqmGWlO2D /H2imDFBilVBbFgdfsSXVwVWqJZiqEpsu7V0TgbGlrFyrcntfDHbFnP/QkqZrWU3ncMz 3EIg== MIME-Version: 1.0 Received: by 10.52.17.82 with SMTP id m18mr6204877vdd.89.1331329435270; Fri, 09 Mar 2012 13:43:55 -0800 (PST) Received: by 10.52.111.136 with HTTP; Fri, 9 Mar 2012 13:43:55 -0800 (PST) Date: Fri, 9 Mar 2012 15:43:55 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec50405d6117e4f04bad64a2c Subject: [clue] Proposal to close Ticket #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:43:56 -0000 --bcaec50405d6117e4f04bad64a2c Content-Type: text/plain; charset=ISO-8859-1 Hi all, There has been a good bit of discussion on this ticket. While the discussion thread very much introduced other topics (which was necessary to understand the context of using the boolean), I believe there is general consensus that the composed attribute is a boolean. Note, that there is another ticket (#5) that relates to describing composed captures. Thus, please continue that discussion under the Ticket #5 thread, which I'll restart. If you have any concerns about the closing of this ticket, please respond by 10am Pacific on Monday, March 12th. As a general note, it is extremely helpful if one is going to expand the discussion of a particular ticket or switch to a related topic, that one start a new thread of discussion or at least change the Subject. The former is preferred. One can include a link to the old discussion in the new thread to set the context if necessary. Regards, Mary - as WG co-chair --bcaec50405d6117e4f04bad64a2c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

There has been a good bit of discussion on this = ticket. =A0While the discussion thread very much introduced other topics (w= hich was necessary to understand the context of using the boolean), =A0I be= lieve there is general consensus that the composed attribute is a boolean. = =A0Note, that there is another ticket (#5) that relates to describing compo= sed captures. =A0Thus, please continue that discussion under the Ticket #5 = thread, which I'll restart. =A0If you have any concerns about the closi= ng of this ticket, please respond by 10am Pacific on Monday, March 12th.=A0=

As a general note, it is extremely helpful if one is go= ing to expand the discussion of a particular ticket or switch to a related = topic, that one start a new thread of discussion or at least change the Sub= ject. =A0The former is preferred. =A0One can include a link to the old disc= ussion in the new thread to set the context if necessary. =A0


Regards,
Mary
- as W= G co-chair
--bcaec50405d6117e4f04bad64a2c-- From mary.ietf.barnes@gmail.com Fri Mar 9 13:47:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C2921E8098 for ; Fri, 9 Mar 2012 13:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.526 X-Spam-Level: X-Spam-Status: No, score=-103.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U1ZBi37G+83T for ; Fri, 9 Mar 2012 13:47:24 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE4DE21E8088 for ; Fri, 9 Mar 2012 13:47:23 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2131313vcb.31 for ; Fri, 09 Mar 2012 13:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=4Hab6JVWPJm+Hr01j5GJNUL8+7Y5mcQVfir+o96eiyQ=; b=xG++37Zqz2HSp5eNFbmeCjdd3jEdLqbiHuTVnMiXlMnGptjCZp1Yy4xJPM404D8+59 sZGnMHEyyG0ullHWzD0Y1ZPyeOKvJ+RyHQ5iM+FuB26tVWGxXgP9bUv8pOh45hWdPBCi 0lVmYdcBYb7ex1Yi5O6Xox0WsY4DZXbmFu9BTjKX/0hf0qsKNCqDbt7qPzQThys0Ctub ch50Q3aLg07X7dl3UweVrppmByAANsX949MIDS3HhTlW89ybBVaUgxw2ZTBmuTcWAZJq OxHiIT9VBvK7ePhhHv/0TBf1G/BEa6WoIGfI7LDGKooDVyM6a9PZ2rJL97KlT/LoMFby 3I6Q== MIME-Version: 1.0 Received: by 10.52.70.165 with SMTP id n5mr6352545vdu.55.1331329641860; Fri, 09 Mar 2012 13:47:21 -0800 (PST) Received: by 10.52.111.136 with HTTP; Fri, 9 Mar 2012 13:47:21 -0800 (PST) Date: Fri, 9 Mar 2012 15:47:21 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec5015e5361cc8104bad65631 Subject: [clue] Ticket #5: Describing composed attributes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:47:24 -0000 --bcaec5015e5361cc8104bad65631 Content-Type: text/plain; charset=ISO-8859-1 Hi all, There was very little feedback to Stephan's proposal: http://www.ietf.org/mail-archive/web/clue/current/msg00765.html for resolution of Ticket #5: http://trac.tools.ietf.org/wg/clue/trac/ticket/5 We do need more WG discussion to resolve this one. Thanks, Mary - as WG co-chair --bcaec5015e5361cc8104bad65631 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

There was very little feedback to Stephan's = proposal:

for resolution of Ticket #5:

We do = need more WG discussion to resolve this one.=A0

Th= anks,
Mary
- as WG co-chair
--bcaec5015e5361cc8104bad65631-- From trac+clue@trac.tools.ietf.org Fri Mar 9 13:58:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9821F8598 for ; Fri, 9 Mar 2012 13:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYfJmiKHHGC3 for ; Fri, 9 Mar 2012 13:58:44 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 77EAE21F858E for ; Fri, 9 Mar 2012 13:58:44 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S67pX-00087K-UY; Fri, 09 Mar 2012 16:58:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 09 Mar 2012 21:58:31 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/8 Message-ID: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309215844.77EAE21F858E@ietfa.amsl.com> Resent-Date: Fri, 9 Mar 2012 13:58:44 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #8: How consumer differentiates between multiple capture scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:58:45 -0000 #8: How consumer differentiates between multiple capture scenes Need to determine how the consumer might differentiate between multiple capture scenes. Need to identify the relevant use cases and requirements. Issue relates to this thread:http://www.ietf.org/mail- archive/web/clue/current/msg01165.html -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Fri Mar 9 13:59:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C242721E80C2 for ; Fri, 9 Mar 2012 13:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.527 X-Spam-Level: X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdyTLMfP-2O6 for ; Fri, 9 Mar 2012 13:59:38 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35D8021E80B4 for ; Fri, 9 Mar 2012 13:59:38 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2151268vcb.31 for ; Fri, 09 Mar 2012 13:59:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=801pCdnLGGQ5GqAy9t5r8bWJTzpojZNtHTkZYJzPAxM=; b=Iwl/228Dd1nrLO2elaTiCdcn6jL6W4SfR56EkpS9/rTuLyIxT1PjZz6jo61jS9UIGH EdZrhtye81iIIJdHK/a22EABC3GBI5RJ2wrHzUef2+Zoq0iwNd5n8oxEVww247SJMoI5 m27E3dYz3XVbpn0vAgKTUOOpRKemaFD1I1PWYGHh9oMoIWGy/hRk4lKUTAgzfr8IBJ5X 7V0xiro8G9G6VsfFAmaTtMTlKTVUngX5cQGVyQiha04E6XFHy1CbLHKvIYnhc3CALtmr YTcdsmw3KsYLdyQx/HwW71N2Z3GDg01ZrXLkeoyk8AE8MIcTkfH+NMXXFFgbCycQDq1W v01A== MIME-Version: 1.0 Received: by 10.52.91.193 with SMTP id cg1mr6432971vdb.21.1331330374248; Fri, 09 Mar 2012 13:59:34 -0800 (PST) Received: by 10.52.111.136 with HTTP; Fri, 9 Mar 2012 13:59:34 -0800 (PST) Date: Fri, 9 Mar 2012 15:59:34 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec5015d230927ce04bad68274 Subject: [clue] New ticket (#8) for how consumer differentiates between multiple capture scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:59:38 -0000 --bcaec5015d230927ce04bad68274 Content-Type: text/plain; charset=ISO-8859-1 One topic that seemed to surface in the discussion of ticket #7 is around how the consumer differentiates between multiple capture scenes: http://www.ietf.org/mail-archive/web/clue/current/msg01165.html A couple things might help in determining a way forward for this one are: 1) Is there a use case that requires this functionality and which is it? ISTM it *might* be 2) If we agree the use case, are the requirements in the requirements document sufficient? I have opened a new ticket to track this issue: http://trac.tools.ietf.org/wg/clue/trac/ticket/8 Please ensure that the ticket # shows up in threads of discussion related to this issue. Regards, Mary - as WG co-chair --bcaec5015d230927ce04bad68274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One topic that seemed to surface in the discussion of ticket #7 is around h= ow the consumer differentiates between multiple capture scenes:

A couple things might help in determining a way forward= for this one are:=A0
1) Is there a use case that requires this f= unctionality and which is it? =A0ISTM it *might* be =A0 =A0
2) If= we agree the use case, are the requirements in the requirements document s= ufficient?

I have opened a new ticket to track this issue:

Please ensure that the ticket # shows up in threads of discussion related t= o this issue.=A0

Regards,
Mary
- as WG co-chair
--bcaec5015d230927ce04bad68274-- From trac+clue@trac.tools.ietf.org Fri Mar 9 14:01:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4B021E80D5 for ; Fri, 9 Mar 2012 14:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maMkVj0x3R8M for ; Fri, 9 Mar 2012 14:01:28 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B0CA521E80C2 for ; Fri, 9 Mar 2012 14:01:28 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S67sN-0000o4-99; Fri, 09 Mar 2012 17:01:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 09 Mar 2012 22:01:27 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://art.tools.ietf.org/wg/clue/trac/ticket/8#comment:1 Message-ID: <083.df8949d66ae2cd4d3b7ee7d5cbdd2e55@trac.tools.ietf.org> References: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309220128.B0CA521E80C2@ietfa.amsl.com> Resent-Date: Fri, 9 Mar 2012 14:01:28 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #8: How consumer differentiates between multiple capture scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:01:29 -0000 #8: How consumer differentiates between multiple capture scenes Changes (by mary.ietf.barnes@…): * type: defect => task -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Fri Mar 9 14:05:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CC621E80BD for ; Fri, 9 Mar 2012 14:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVYlWTfm73Qg for ; Fri, 9 Mar 2012 14:05:36 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8BF21E80B8 for ; Fri, 9 Mar 2012 14:05:36 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S67wJ-0007kA-Fr; Fri, 09 Mar 2012 17:05:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 09 Mar 2012 22:05:31 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/9 Message-ID: <068.55b235ae09bcadb5a9adc0e971bc9935@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309220536.6B8BF21E80B8@ietfa.amsl.com> Resent-Date: Fri, 9 Mar 2012 14:05:36 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #9: Axis of capture description X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:05:37 -0000 #9: Axis of capture description Currently, the access of capture is undefined in the framework document. Per this thread, we need to agree text to describe the "Axis of capture": http://www.ietf.org/mail-archive/web/clue/current/msg01158.html -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From mary.ietf.barnes@gmail.com Fri Mar 9 14:07:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC921E8088 for ; Fri, 9 Mar 2012 14:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq5WAVKcmINa for ; Fri, 9 Mar 2012 14:07:53 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43FAA21E80E2 for ; Fri, 9 Mar 2012 14:07:53 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2160715vcb.31 for ; Fri, 09 Mar 2012 14:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=V74OKcsesWzRc5bttNRRO/p0qAhRsedNroy7fauDY1A=; b=rBjL7AJsP3hndxg4AFYgKEW85P4AkTHz0QyOoWVrf3pR3MqTKaoL7ZLEwLoiqzMR2y uYfTy84W61Sj3L4EwCrXv80zcUMMSxIqEOSgt8QwgrMXfw51uR3Oz/n7PEFxEIv8jJla aCiUubpQytf58CUxplOJOgKclUuwUYd8diU5lcwVB3tiHbwWxV6mNC0mEUBooiKi7ytQ QPhgjbZnG6nUo3Xg9fzcpuZaAmduJAa4OJDOTZRb81Z0tVWDg8bf5takAwZLxqUUIMRd yFLDzMTIXoRIAw7A52DEXQBNiROKDHlNUURtWVRqJYvqFPRfQOy+eTy81EHdbNgOm57j zYHQ== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr6449867vdh.38.1331330872010; Fri, 09 Mar 2012 14:07:52 -0800 (PST) Received: by 10.52.111.136 with HTTP; Fri, 9 Mar 2012 14:07:51 -0800 (PST) Date: Fri, 9 Mar 2012 16:07:51 -0600 Message-ID: From: Mary Barnes To: Stephan Wenger Content-Type: multipart/alternative; boundary=20cf3079bc9eb4669d04bad69fff Cc: "clue@ietf.org" Subject: [clue] New Ticket #9 (was Re: Language re capture axis X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:07:54 -0000 --20cf3079bc9eb4669d04bad69fff Content-Type: text/plain; charset=ISO-8859-1 Please note that I've opened a ticket to track this issue: http://trac.tools.ietf.org/wg/clue/trac/ticket/9 If folks could please keep the ticket #9 in the Subject when discussing this topic, that would be very helpful. Thanks, Mary. - as CLUE WG co-chair On Tue, Mar 6, 2012 at 6:34 PM, Stephan Wenger wrote: > With the understanding that "out of this version" means "out of this > interation of the I-D", I'm fine. I still want this in the published RFC. > Same goes for (de)composition info. > I will propose text as soon as I find the cycles (not before the Paris I-D > deadline). > > Stephan > > > On 3.6.2012 14:51 , "Paul Kyzivat" wrote: > > >On 3/5/12 1:29 PM, Duckworth, Mark wrote: > >> As editor, it seems I should leave this out of the next version. Okay? > > > >I'm ok with leaving any mention of it out, assuming those who were > >concerned about it (Stephan) are ok with that. > > > > Paul > > > >> Otherwise, I would appreciate having interested parties propose new > >>text to discuss on the mailing list, considering Paul's desire to have > >>more specific text than what we have previously discussed. > >> > >> Thanks, > >> Mark > >> > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>> Sent: Thursday, March 01, 2012 4:53 PM > >>> To: Duckworth, Mark > >>> Cc: clue@ietf.org > >>> Subject: Re: [clue] Language re capture axis > >>> > >>> On 2/29/12 11:14 AM, Duckworth, Mark wrote: > >>>> Paul and Stephan, > >>>> > >>>> Personally, I'd rather just leave it out altogether because I think > >>>>it doesn't > >>> add anything that needs to be standardized. But Stephan thought it was > >>> important, so I was trying to find a way to say it in an "accurate > >>>enough" way. > >>> > >>> If there is no widespread interest in having this, and those who have > >>>asked > >>> about it are happy without, then I'm fine with leaving it out. > >>> > >>> If it is to be mentioned, with the idea that the recipient might use > >>>it for > >>> something, then I think it should be made clear how it can be > >>>determined. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Mark > >>>> > >>>>> -----Original Message----- > >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >>>>> Of Paul Kyzivat > >>>>> Sent: Wednesday, February 29, 2012 10:56 AM > >>>>> To: clue@ietf.org > >>>>> Subject: Re: [clue] Language re capture axis > >>>>> > >>>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote: > >>>>>> Hi Stephan, > >>>>>> > >>>>>> I agree in principle with your suggestion, but I think your > >>>>>> suggested text is not mathematically accurate. I think the axis of > >>>>>> capture doesn't go to the center of the area of capture. For > >>>>>> example, if the camera is pointed at the area of capture at an > >>>>>> angle, the center point of the area would not line up with the > >>>>>> center point of the camera's field of view (which defines the axis). > >>>>>> > >>>>>> So rather than try to get into the mathematical details, how about > >>>>>>this: > >>>>>> > >>>>>> "Note that, for the purpose of receiver-side geometric correction, > >>>>>> it can be assumed that the axis of capture of directional capture > >>>>>> devices (cameras, directional microphones etc.) can be calculated > >>>>>> from the coordinates of the point of capture and area of capture." > >>>>> > >>>>> IMO this is dangerously vague. Presumably there is a real axis of > >>>>>capture. > >>>>> Hopefully there is a well defined algorithm for deriving the axis > >>>>> from the available data, so that the recipient will determine the > >>>>> actual axis. If so, then it should be specified or referenced from > >>>>> some source. Otherwise we run the risk that not all will correctly > >>>>>derive > >>> the axis. > >>>>> > >>>>> Thanks, > >>>>> Paul > >>>>> > >>>>>> Mark > >>>>>> > >>>>>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On > >>>>>> Behalf Of *Stephan Wenger > >>>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM > >>>>>> *To:* clue@ietf.org > >>>>>> *Subject:* [clue] Language re capture axis > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> The issue I mentioned in the meeting is that nowhere in the > >>>>>> framework (as far as I recall) the axis of capture of a video > >>>>>> capture (or directional audio capture-anything that is not > >>>>>> omnidirectional) is undefined. Without that axis being defined, > >>>>>> receiver-side geometric correction is not possible. > >>>>>> > >>>>>> The issue could be solved in two ways: include attributes, per > >>>>>> capture, indicating angle of capture in 3D space (relative to > >>>>>> what???), or by making the bold assumption that the coordinates > >>>>>> defining area of capture plus capture point define the axis of > >>>>>> capture. I suggest the latter as it is easy to implement and (I > >>>>>> believe) > >>>>> practical. > >>>>>> > >>>>>> The language could be something like: > >>>>>> > >>>>>> " > >>>>>> > >>>>>> Note that, for the purpose of receiver-side geometric correction, it > >>>>>> can be assumed that the axis of capture of directional capture > >>>>>> devices (cameras, directional microphones etc.) is the line from the > >>>>>> capture point to the center of the plane of capture. > >>>>>> > >>>>>> " > >>>>>> > >>>>>> Stephan > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> clue mailing list > >>>>>> clue@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/clue > >>>>> > >>>>> _______________________________________________ > >>>>> clue mailing list > >>>>> clue@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >> > >> > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf3079bc9eb4669d04bad69fff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please note that I've opened a ticket to track this issue:

If folks could ple= ase keep the ticket #9 in the Subject when discussing this topic, that woul= d be very helpful.

Thanks,
Mary.
- as CLUE WG co-chair=


On Tue, Mar 6, 201= 2 at 6:34 PM, Stephan Wenger <stewe@stewe.org> wrote:
With the understanding that "out of thi= s version" means "out of this
interation of the I-D", I'm fine. =A0I still want this in the publ= ished RFC.
=A0Same goes for (de)composition info.
I will propose text as soon as I find the cycles (not before the Paris I-D<= br> deadline).

Stephan


On 3.6.2012 14:51 , "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:

>On 3/5/12 1:29 PM, Duckworth, Mark wrote:
>> As editor, it seems I should leave this out of the next version. = =A0Okay?
>
>I'm ok with leaving any mention of it out, assuming those who were<= br> >concerned about it (Stephan) are ok with that.
>
> =A0 =A0 =A0 Paul
>
>> Otherwise, I would appreciate having interested parties propose ne= w
>>text to discuss on the mailing list, considering Paul's desire = to have
>>more specific text than what we have previously discussed.
>>
>> Thanks,
>> Mark
>>
>>> -----Original Message-----
>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>>> Sent: Thursday, March 01, 2012 4:53 PM
>>> To: Duckworth, Mark
>>> Cc: clue@ietf.org
>>> Subject: Re: [clue] Language re capture axis
>>>
>>> On 2/29/12 11:14 AM, Duckworth, Mark wrote:
>>>> Paul and Stephan,
>>>>
>>>> Personally, I'd rather just leave it out altogether be= cause I think
>>>>it doesn't
>>> add anything that needs to be standardized. =A0But Stephan tho= ught it was
>>> important, so I was trying to find a way to say it in an "= ;accurate
>>>enough" way.
>>>
>>> If there is no widespread interest in having this, and those w= ho have
>>>asked
>>> about it are happy without, then I'm fine with leaving it = out.
>>>
>>> If it is to be mentioned, with the idea that the recipient mig= ht use
>>>it for
>>> something, then I think it should be made clear how it can be<= br> >>>determined.
>>>
>>> =A0 =A0 Thanks,
>>> =A0 =A0 Paul
>>>
>>>> Mark
>>>>
>>>>> -----Original Message-----
>>>>> From: clue-bo= unces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf
>>>>> Of Paul Kyzivat
>>>>> Sent: Wednesday, February 29, 2012 10:56 AM
>>>>> To: clue@ietf.org=
>>>>> Subject: Re: [clue] Language re capture axis
>>>>>
>>>>> On 2/29/12 10:10 AM, Duckworth, Mark wrote:
>>>>>> Hi Stephan,
>>>>>>
>>>>>> I agree in principle with your suggestion, but I t= hink your
>>>>>> suggested text is not mathematically accurate. I t= hink the axis of
>>>>>> capture doesn't go to the center of the area o= f capture. For
>>>>>> example, if the camera is pointed at the area of c= apture at an
>>>>>> angle, the center point of the area would not line= up with the
>>>>>> center point of the camera's field of view (wh= ich defines the axis).
>>>>>>
>>>>>> So rather than try to get into the mathematical de= tails, how about
>>>>>>this:
>>>>>>
>>>>>> "Note that, for the purpose of receiver-side = geometric correction,
>>>>>> it can be assumed that the axis of capture of dire= ctional capture
>>>>>> devices (cameras, directional microphones etc.) ca= n be calculated
>>>>>> from the coordinates of the point of capture and a= rea of capture."
>>>>>
>>>>> IMO this is dangerously vague. Presumably there is a r= eal axis of
>>>>>capture.
>>>>> Hopefully there is a well defined algorithm for derivi= ng the axis
>>>>> from the available data, so that the recipient will de= termine the
>>>>> actual axis. If so, then it should be specified or ref= erenced from
>>>>> some source. Otherwise we run the risk that not all wi= ll correctly
>>>>>derive
>>> the axis.
>>>>>
>>>>> =A0 Thanks,
>>>>> =A0 Paul
>>>>>
>>>>>> Mark
>>>>>>
>>>>>> *From:*cl= ue-bounces@ietf.org [mailto:cl= ue-bounces@ietf.org] *On
>>>>>> Behalf Of *Stephan Wenger
>>>>>> *Sent:* Wednesday, February 15, 2012 11:04 AM
>>>>>> *To:* clue@ietf.o= rg
>>>>>> *Subject:* [clue] Language re capture axis
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The issue I mentioned in the meeting is that nowhe= re in the
>>>>>> framework (as far as I recall) the axis of capture= of a video
>>>>>> capture (or directional audio capture-anything tha= t is not
>>>>>> omnidirectional) is undefined. Without that axis b= eing defined,
>>>>>> receiver-side geometric correction is not possible= .
>>>>>>
>>>>>> The issue could be solved in two ways: include att= ributes, per
>>>>>> capture, indicating angle of capture in 3D space (= relative to
>>>>>> what???), or by making the bold assumption that th= e coordinates
>>>>>> defining area of capture plus capture point define= the axis of
>>>>>> capture. I suggest the latter as it is easy to imp= lement and (I
>>>>>> believe)
>>>>> practical.
>>>>>>
>>>>>> The language could be something like:
>>>>>>
>>>>>> "
>>>>>>
>>>>>> Note that, for the purpose of receiver-side geomet= ric correction, it
>>>>>> can be assumed that the axis of capture of directi= onal capture
>>>>>> devices (cameras, directional microphones etc.) is= the line from the
>>>>>> capture point to the center of the plane of captur= e.
>>>>>>
>>>>>> "
>>>>>>
>>>>>> Stephan
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________ >>>>>> clue mailing list
>>>>>> clue@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> clue@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>
>>
>>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue
>


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf3079bc9eb4669d04bad69fff-- From trac+clue@trac.tools.ietf.org Fri Mar 9 14:08:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D413521E80E8 for ; Fri, 9 Mar 2012 14:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrLey2fhtmRZ for ; Fri, 9 Mar 2012 14:08:24 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 497D721E80E2 for ; Fri, 9 Mar 2012 14:08:23 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S67z3-000848-V2; Fri, 09 Mar 2012 17:08:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 09 Mar 2012 22:08:21 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/8#comment:2 Message-ID: <083.853624688f0c47f3615c1bbadc361c99@trac.tools.ietf.org> References: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <068.588d2435268c3816b1025ee877475a97@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309220824.497D721E80E2@ietfa.amsl.com> Resent-Date: Fri, 9 Mar 2012 14:08:23 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #8: How consumer differentiates between multiple capture scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:08:24 -0000 #8: How consumer differentiates between multiple capture scenes Description changed by mary.ietf.barnes@…: Old description: > Need to determine how the consumer might differentiate between multiple > capture scenes. Need to identify the relevant use cases and > requirements. Issue relates to this thread:http://www.ietf.org/mail- > archive/web/clue/current/msg01165.html New description: Need to determine how the consumer might differentiate between multiple capture scenes. Need to identify the relevant use cases and requirements. Issue relates to this thread: http://www.ietf.org/mail- archive/web/clue/current/msg01165.html -- -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From pkyzivat@alum.mit.edu Fri Mar 9 14:08:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6135821E8093 for ; Fri, 9 Mar 2012 14:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4AqU3ASBFpU for ; Fri, 9 Mar 2012 14:08:42 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDC421E80EE for ; Fri, 9 Mar 2012 14:08:40 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta05.westchester.pa.mail.comcast.net with comcast id ja7d1i0020xGWP855a8gDG; Fri, 09 Mar 2012 22:08:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id ja8g1i00f07duvL3Ya8gJw; Fri, 09 Mar 2012 22:08:40 +0000 Message-ID: <4F5A7F66.1070206@alum.mit.edu> Date: Fri, 09 Mar 2012 17:08:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Mary Barnes References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:08:43 -0000 On 3/9/12 4:21 PM, Mary Barnes wrote: > Paul, > > I'm trying to discern if we have consensus on the basic question of > whether people are okay with replacing the term "capture set" with > "capture scene" using the definitions that Mark has below. Paul, can > you please clarify two things for the WG: > 1) That you are speaking as an individual in the threads (i.e., you are > not trying to evaluate the thread for consensus) Sorry for not making it clear. I have indeed been speaking as an individual in this discussion. > 2) I *think* you are disagreeing with Mark's proposal, but that's not > clear to me. I think you are suggesting that "Capture Scene" be defined > to have a more information than just capture scene entries. Is that > correct? I very much am in favor of Capture Scene replacing Capture Set. As far as I am concerned that can happen and we can continue to discuss the nuances of what is in a Capture Scene. Another related question was whether there can be more than one Capture Scene per advertisement. But I think it has now been settled that there can. The rest may be a tempest in a tea pot. I'm surprised there seems to be so much controversy. Its about how many and what sort of Capture Scenes might appear in an advertisement from an MCU. Of course we don't really have to settle that now, or ever. I've been arguing that when there are multiple Scenes in an advertisement there should be some added attribute(s) available to help distinguish them. But we don't have to settle that soon either. Thanks, Paul > Thanks, > Mary. > - as WG co-chair > > On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat > wrote: > > On 3/5/12 2:16 PM, Duckworth, Mark wrote: > > At the interim meeting, there was some support for combining the > concepts of “capture scene” and “capture set” into a single > concept. So > here is a rough proposal for doing that, essentially using the term > “capture scene” to replace the previous term “capture set”, and > eliminating the original separate capture scene concept. > > Definitions: > > *Capture Scene: a structure representing the scene that is > captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. > > *Capture Scene Entry: a list of media captures of the same media > type > that together form one way to represent the capture scene. > > > One of the reasons I preferred "Capture Scene" to "Capture Set" is > that "set" implied to me that it is *only* a set of captures. But in > fact there are already other attributes in addition to the set of > captures (such as the purpose), and there will probably be more as > we proceed. > > To me, "Capture Scene Entry" conveys some of that same assumption. > Namely, that a Capture Scene" is made up of a number of Capture > Scene Entries, which seems to exclude other attributes that are not > Capture Scene Entries. > > It would feel more natural to me to have a Capture Set that is a set > of media captures. (That is, what was previously called a Capture > Set Entry.) And then define another term for a grouping of these > Capture Sets. I'm having trouble coming up with a term for that > which matches the intent well, but as a swag, how about Capture Set > Alternatives. > > So then you would have a logical structure something like: > > - Advertisement > - Capture Scene (one or more) > - Description > - Purpose > - Area of Scene > - Capture Set Alternatives (one or more) > - Capture Set (one or more) > - Capture > > I don't think Capture Set Alternatives is the right term. I think I > am hampered in finding a better term by not really having a crisp > understanding of the reason for having this grouping. Its partly > about alternatives in that there is an expectation that for a > particular medium you would choose only one. But its not about > alternatives in that you need to choose audio and video > independently. Also, that is only an approximation - there seem to > be expected cases when entries from more than one video entry would > be chosen. > > In my experience, when its hard to find a good term it usually means > that the thing being named is not sufficiently defined and likely > can be factored into more meaningful pieces. > > Thanks, > Paul > > Text for section 6.2 Capture Scene (was 6.2 Capture Set): > > A capture scene represents, for example, the video image of a > group of > people seated next to each other, along with the sound of their > voices, > which could be represented by some number of VCs and ACs in the > capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives. > > A media provider arranges media captures in a capture scene to > help the > media consumer choose which captures it wants. The capture scene > entries > in a capture scene are different alternatives the provider is > suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each > media > type (e.g. audio and video), or it can pick and choose media > captures > regardless of how the provider arranges them in capture scene > entries. > > A capture scene may include more than one type of media. For > example, a > capture scene can include several capture scene entries for video > captures, and several capture scene entries for audio captures. > > (This text would be worked into section 6.2, not replace it > completely. > Other things in section 6.2 and elsewhere would need to be > edited to be > consistent with the new terminology in this proposal) > > Regards, > > Mark > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > From trac+clue@trac.tools.ietf.org Fri Mar 9 14:09:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C0D21E8047 for ; Fri, 9 Mar 2012 14:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rleCbbE8lx+W for ; Fri, 9 Mar 2012 14:09:09 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 607B921E8044 for ; Fri, 9 Mar 2012 14:09:09 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S67zc-00084y-Hu; Fri, 09 Mar 2012 17:08:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Fri, 09 Mar 2012 22:08:56 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://art.tools.ietf.org/wg/clue/trac/ticket/5#comment:2 Message-ID: <078.2bece4336b295b0a9d422a8ce966e668@trac.tools.ietf.org> References: <063.a37bc5dd4fc60cc1fce0e69ad3a0e316@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <063.a37bc5dd4fc60cc1fce0e69ad3a0e316@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, Stephan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120309220909.607B921E8044@ietfa.amsl.com> Resent-Date: Fri, 9 Mar 2012 14:09:09 -0800 (PST) Resent-From: trac+clue@trac.tools.ietf.org Cc: Stephan@vidyo.com, clue@ietf.org Subject: Re: [clue] #5: Describing composed captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:09:09 -0000 #5: Describing composed captures Description changed by mary.ietf.barnes@…: Old description: > Stephan Wenger to make proposal for describing composed captures, by mid > December, 2011. > > Update: Stephan made the following proposal:http://www.ietf.org/mail- > archive/web/clue/current/msg00765.html > > Need addt'l WG feedback on this proposal. New description: Stephan Wenger to make proposal for describing composed captures, by mid December, 2011. Update: Stephan made the following proposal: http://www.ietf.org/mail- archive/web/clue/current/msg00765.html Need addt'l WG feedback on this proposal. -- -- --------------------------------+------------------------------------------ Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From Even.roni@huawei.com Fri Mar 9 14:27:11 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B97A21F8615 for ; Fri, 9 Mar 2012 14:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.57 X-Spam-Level: X-Spam-Status: No, score=-106.57 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y03-d0tTKRe for ; Fri, 9 Mar 2012 14:27:10 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 33E7F21F85F4 for ; Fri, 9 Mar 2012 14:27:10 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0N00I392D3J6@szxga04-in.huawei.com> for clue@ietf.org; Sat, 10 Mar 2012 06:27:03 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0N009E42D38P@szxga04-in.huawei.com> for clue@ietf.org; Sat, 10 Mar 2012 06:27:03 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHJ46571; Sat, 10 Mar 2012 06:27:02 +0800 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 10 Mar 2012 06:26:28 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.003; Sat, 10 Mar 2012 06:27:00 +0800 Date: Fri, 09 Mar 2012 22:27:00 +0000 From: Roni even In-reply-to: X-Originating-IP: [172.24.1.67] To: Mary Barnes , CLUE Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Y3Iq3wxoChNVuGoLK/8J6w)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [clue] Proposal to close Ticket #7: Is composed attribute a boolean or data structure Thread-index: AQHM/j2/PcFc17b+HUmO7sFvyHKvdJZiiMXm X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [clue] Proposal to close Ticket #7: Is composed attribute a boolean or data structure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:27:11 -0000 --Boundary_(ID_Y3Iq3wxoChNVuGoLK/8J6w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, I am not objecting to have it as Boolean but I will insist that the text in the framework that claim what is the view like VC4 in section 11.1 must be changed to reflect that the description (the loudest panel stream with PiPs) cannot be conveyed from the provider to the consumer using these attributes. This should also be clear from the description of the attribute by adding text in 6.1.1 like, "the provider cannot assume that the consumer will understand what is included the mix and will expect to receive any mix that the provider will think is adequate. " Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Friday, March 09, 2012 23:43 To: CLUE Subject: [clue] Proposal to close Ticket #7: Is composed attribute a boolean or data structure Hi all, There has been a good bit of discussion on this ticket. While the discussion thread very much introduced other topics (which was necessary to understand the context of using the boolean), I believe there is general consensus that the composed attribute is a boolean. Note, that there is another ticket (#5) that relates to describing composed captures. Thus, please continue that discussion under the Ticket #5 thread, which I'll restart. If you have any concerns about the closing of this ticket, please respond by 10am Pacific on Monday, March 12th. As a general note, it is extremely helpful if one is going to expand the discussion of a particular ticket or switch to a related topic, that one start a new thread of discussion or at least change the Subject. The former is preferred. One can include a link to the old discussion in the new thread to set the context if necessary. Regards, Mary - as WG co-chair --Boundary_(ID_Y3Iq3wxoChNVuGoLK/8J6w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Hi,

I am not objecting to have it as Boolean but I will insist that the text in the framework that claim what is the view like VC4 in section 11.1 must be changed to reflect that the description (the loudest panel stream with PiPs) cannot be conveyed from the provider to the consumer using these attributes. This should also be clear from the description of the attribute by adding text in 6.1.1 like, "the provider cannot assume that the consumer will understand what is included the mix and will expect to receive any mix that the provider will think is adequate. "

Roni

From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Friday, March 09, 2012 23:43
To: CLUE
Subject: [clue] Proposal to close Ticket #7: Is composed attribute a boolean or data structure

Hi all,

There has been a good bit of discussion on this ticket.  While the discussion thread very much introduced other topics (which was necessary to understand the context of using the boolean),  I believe there is general consensus that the composed attribute is a boolean.  Note, that there is another ticket (#5) that relates to describing composed captures.  Thus, please continue that discussion under the Ticket #5 thread, which I'll restart.  If you have any concerns about the closing of this ticket, please respond by 10am Pacific on Monday, March 12th. 

As a general note, it is extremely helpful if one is going to expand the discussion of a particular ticket or switch to a related topic, that one start a new thread of discussion or at least change the Subject.  The former is preferred.  One can include a link to the old discussion in the new thread to set the context if necessary.  


Regards,
Mary
- as WG co-chair
--Boundary_(ID_Y3Iq3wxoChNVuGoLK/8J6w)-- From Even.roni@huawei.com Fri Mar 9 14:40:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80F221E80A6 for ; Fri, 9 Mar 2012 14:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.738 X-Spam-Level: X-Spam-Status: No, score=-105.738 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIXtZ1XDP2sv for ; Fri, 9 Mar 2012 14:40:51 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06A21E805F for ; Fri, 9 Mar 2012 14:40:51 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0N00FHY30220@szxga04-in.huawei.com> for clue@ietf.org; Sat, 10 Mar 2012 06:40:50 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0N009L53028P@szxga04-in.huawei.com> for clue@ietf.org; Sat, 10 Mar 2012 06:40:50 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHJ46737; Sat, 10 Mar 2012 06:40:49 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 10 Mar 2012 06:40:28 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.220]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Sat, 10 Mar 2012 06:40:45 +0800 Date: Fri, 09 Mar 2012 22:40:43 +0000 From: Roni even In-reply-to: X-Originating-IP: [172.24.1.67] To: Mary Barnes , Paul Kyzivat Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Ce1bKhXx7J1vGTRr06Zytg)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [clue] Proposal to combine capture scene and capture set Thread-index: Acz7BEjU/dWlSEAnQuC91hY5WY2g+gAkLwwAAJiiIAAAE12OYA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:40:53 -0000 --Boundary_(ID_Ce1bKhXx7J1vGTRr06Zytg) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: quoted-printable Mary, I have no problem with having just capture scene and taking out the capture= set. This is a very minor issue in the discussion. I hope we can have an agreed text on simultaneous capabilities and capture = scene entries and how a consumer selects a configuration As for the MCU case you mention, my view is that this is not a CLUE issue b= ut a general MCU problem of source selection by participants and you can se= e some discussion in draft-lennox-mmusic-sdp-source-selection-03 Roni Even ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Friday, March 09, 2012 23:21 To: Paul Kyzivat Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set Paul, I'm trying to discern if we have consensus on the basic question of whether= people are okay with replacing the term "capture set" with "capture scene"= using the definitions that Mark has below. Paul, can you please clarify= two things for the WG: 1) That you are speaking as an individual in the threads (i.e., you are not= trying to evaluate the thread for consensus) 2) I *think* you are disagreeing with Mark's proposal, but that's not clea= r to me. I think you are suggesting that "Capture Scene" be defined to hav= e a more information than just capture scene entries. Is that correct? Thanks, Mary. - as WG co-chair On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat > wrote: On 3/5/12 2:16 PM, Duckworth, Mark wrote: At the interim meeting, there was some support for combining the concepts of =93capture scene=94 and =93capture set=94 into a single concept= . So here is a rough proposal for doing that, essentially using the term =93capture scene=94 to replace the previous term =93capture set=94, and eliminating the original separate capture scene concept. Definitions: *Capture Scene: a structure representing the scene that is captured by a collection of capture devices. A capture scene includes one or more capture scene entries, with each entry including one or more media captures. *Capture Scene Entry: a list of media captures of the same media type that together form one way to represent the capture scene. One of the reasons I preferred "Capture Scene" to "Capture Set" is that "se= t" implied to me that it is *only* a set of captures. But in fact there are= already other attributes in addition to the set of captures (such as the p= urpose), and there will probably be more as we proceed. To me, "Capture Scene Entry" conveys some of that same assumption. Namely, = that a Capture Scene" is made up of a number of Capture Scene Entries, whic= h seems to exclude other attributes that are not Capture Scene Entries. It would feel more natural to me to have a Capture Set that is a set of med= ia captures. (That is, what was previously called a Capture Set Entry.) And= then define another term for a grouping of these Capture Sets. I'm having = trouble coming up with a term for that which matches the intent well, but a= s a swag, how about Capture Set Alternatives. So then you would have a logical structure something like: - Advertisement - Capture Scene (one or more) - Description - Purpose - Area of Scene - Capture Set Alternatives (one or more) - Capture Set (one or more) - Capture I don't think Capture Set Alternatives is the right term. I think I am hamp= ered in finding a better term by not really having a crisp understanding of= the reason for having this grouping. Its partly about alternatives in that= there is an expectation that for a particular medium you would choose only= one. But its not about alternatives in that you need to choose audio and v= ideo independently. Also, that is only an approximation - there seem to be = expected cases when entries from more than one video entry would be chosen. In my experience, when its hard to find a good term it usually means that t= he thing being named is not sufficiently defined and likely can be factored= into more meaningful pieces. Thanks, Paul Text for section 6.2 Capture Scene (was 6.2 Capture Set): A capture scene represents, for example, the video image of a group of people seated next to each other, along with the sound of their voices, which could be represented by some number of VCs and ACs in the capture scene entries. A middle box may also express capture scenes that it constructs from media streams it receives. A media provider arranges media captures in a capture scene to help the media consumer choose which captures it wants. The capture scene entries in a capture scene are different alternatives the provider is suggesting for representing the capture scene. The media consumer can choose to receive all media captures from one capture scene entry for each media type (e.g. audio and video), or it can pick and choose media captures regardless of how the provider arranges them in capture scene entries. A capture scene may include more than one type of media. For example, a capture scene can include several capture scene entries for video captures, and several capture scene entries for audio captures. (This text would be worked into section 6.2, not replace it completely. Other things in section 6.2 and elsewhere would need to be edited to be consistent with the new terminology in this proposal) Regards, Mark _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --Boundary_(ID_Ce1bKhXx7J1vGTRr06Zytg) Content-type: text/html; charset=Windows-1252 Content-transfer-encoding: quoted-printable

Mary,

I have no problem with having just capture scene and taking out the capt= ure set. This is a very minor issue in the discussion.

 

I hope we can have an agreed text on simultaneous capab= ilities and capture scene entries and how a consumer selects a confi= guration

 

As for the MCU case you mention, my view is that this is not a CLUE issu= e but a general MCU problem of source selection by participants and yo= u can see some discussion in draft-lennox-mmusic-sdp-source-selection-03

 

Roni Even

From: clue-bounces@ietf.org [clue-bounces@= ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Friday, March 09, 2012 23:21
To: Paul Kyzivat
Cc: clue@ietf.org
Subject: Re: [clue] Proposal to combine capture scene and capture se= t

Paul,

I'm trying to discern if we have consensus on the basic question of whether= people are okay with replacing the term "capture set" with "= ;capture scene" using the definitions that Mark has below.   &nbs= p;Paul, can you please clarify two things for the WG:
1) That you are speaking as an individual in the threads (i.e., you ar= e not trying to evaluate the thread for consensus)
2)  I *think* you are disagreeing with Mark's proposal, but that'= s not clear to me.  I think you are suggesting that "Capture Scen= e" be defined to have a more information than just capture scene entri= es.  Is that correct?

Thanks,
Mary.
- as WG co-chair

On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat <pkyzivat@alu= m.mit.edu> wrote:
On 3/5/12 2:16 PM, Duckworth, Mark wrote:
At the interim meeting, there was some support for combining the
concepts of =93capture scene=94 and =93capture set=94 into a single concept= . So
here is a rough proposal for doing that, essentially using the term
=93capture scene=94 to replace the previous term =93capture set=94, and
eliminating the original separate capture scene concept.

Definitions:

*Capture Scene: a structure representing the scene that is captured by a collection of capture devices. A capture scene includes one or more
capture scene entries, with each entry including one or more media
captures.

*Capture Scene Entry: a list of media captures of the same media type
that together form one way to represent the capture scene.

One of the reasons I preferred "Capture Scene" to "Capture S= et" is that "set" implied to me that it is *only* a set of c= aptures. But in fact there are already other attributes in addition to the = set of captures (such as the purpose), and there will probably be more as we proceed.

To me, "Capture Scene Entry" conveys some of that same assumption= . Namely, that a Capture Scene" is made up of a number of Capture Scen= e Entries, which seems to exclude other attributes that are not Capture Sce= ne Entries.

It would feel more natural to me to have a Capture Set that is a set of med= ia captures. (That is, what was previously called a Capture Set Entry.) And= then define another term for a grouping of these Capture Sets. I'm having = trouble coming up with a term for that which matches the intent well, but as a swag, how about Capture Set A= lternatives.

So then you would have a logical structure something like:

- Advertisement
 - Capture Scene (one or more)
   - Description
   - Purpose
   - Area of Scene
   - Capture Set Alternatives (one or more)
     - Capture Set (one or more)
       - Capture

I don't think Capture Set Alternatives is the right term. I think I am hamp= ered in finding a better term by not really having a crisp understanding of= the reason for having this grouping. Its partly about alternatives in that= there is an expectation that for a particular medium you would choose only one. But its not about alternati= ves in that you need to choose audio and video independently. Also, that is= only an approximation - there seem to be expected cases when entries from = more than one video entry would be chosen.

In my experience, when its hard to find a good term it usually means that t= he thing being named is not sufficiently defined and likely can be factored= into more meaningful pieces.

       Thanks,
       Paul
Text for section 6.2 Capture Scene (was 6.2 Capture Set):=

A capture scene represents, for example, the video image of a group of
people seated next to each other, along with the sound of their voices,
which could be represented by some number of VCs and ACs in the capture
scene entries. A middle box may also express capture scenes that it
constructs from media streams it receives.

A media provider arranges media captures in a capture scene to help the
media consumer choose which captures it wants. The capture scene entries in a capture scene are different alternatives the provider is suggesting for representing the capture scene. The media consumer can choose to
receive all media captures from one capture scene entry for each media
type (e.g. audio and video), or it can pick and choose media captures
regardless of how the provider arranges them in capture scene entries.

A capture scene may include more than one type of media. For example, a
capture scene can include several capture scene entries for video
captures, and several capture scene entries for audio captures.

(This text would be worked into section 6.2, not replace it completely.
Other things in section 6.2 and elsewhere would need to be edited to be
consistent with the new terminology in this proposal)

Regards,

Mark



_______________________________________________ clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--Boundary_(ID_Ce1bKhXx7J1vGTRr06Zytg)-- From pkyzivat@alum.mit.edu Fri Mar 9 14:47:54 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D4921F85A7 for ; Fri, 9 Mar 2012 14:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVJNqnJaNg79 for ; Fri, 9 Mar 2012 14:47:54 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 278D121F85A2 for ; Fri, 9 Mar 2012 14:47:54 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta08.westchester.pa.mail.comcast.net with comcast id jafh1i0021HzFnQ58anuPg; Fri, 09 Mar 2012 22:47:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id janu1i00l07duvL3aanuQY; Fri, 09 Mar 2012 22:47:54 +0000 Message-ID: <4F5A8898.3050504@alum.mit.edu> Date: Fri, 09 Mar 2012 17:47:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: CLUE References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] New ticket (#8) for how consumer differentiates between multiple capture scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:47:54 -0000 Thanks Mary for standing back and pointing out I had created another issue. Since I seem to have been the guilty party in bringing this up, I can kick off the discussion. On 3/9/12 4:59 PM, Mary Barnes wrote: > One topic that seemed to surface in the discussion of ticket #7 is > around how the consumer differentiates between multiple capture scenes: > http://www.ietf.org/mail-archive/web/clue/current/msg01165.html > > A couple things might help in determining a way forward for this one are: > 1) Is there a use case that requires this functionality and which is it? > ISTM it *might* be I was thinking of an MCU that decides it wants to "pass through" Capture Scenes it receives. Thus the advertisements it makes could include a separate Capture Scene or Scenes from each endpoint participating in the conference. (Of course it could include just an interesting subset of these, or also include some other Scenes that it synthesizes, but lets stick with this for discussion.) So if rooms X,Y,Z are connected to the MCU, each might have one scene containing captures for all of its cameras, and another scene containing a presentation. So the advertisement from the MCU to Z would contain four scenes, two from X and two Y. In a typical case the captures from all the cameras might have purpose=main, while presentation captures have purpose=presentation. But there is no obvious way to tell which captures come from X and which come from Y. This could be handled either by attributes on the individual captures, or by attributes on the capture scenes. I don't see how this would help with algorithmically sorting things out, but at least it could provide some data for a UI display to pick what to display. I don't see anything currently defined in the framework that meets this need. A simple text description of each capture, or of the scene, would probably be sufficient. > 2) If we agree the use case, are the requirements in the requirements > document sufficient? This may be covered by REQMT-1 which requires support for describing the spacial arrangement of sources. What we have specified so far describes the spacial arrangement of sources within a single scene. But it isn't capable of describing the spacial arrangement of sources within multiple scenes from different sources. (Though I'm talking about a textual description, which is something like a civil address, rather than a coordinate.) This also might, in part, be covered by REQMT-15 about presentations, because if there is more than one presentation there is currently no way to indicate the meaning of each, even if they are in a single scene. We can discuss if those are sufficient, or if there is some different requirement here. Thanks, Paul From pkyzivat@alum.mit.edu Fri Mar 9 15:34:24 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE16221E8019 for ; Fri, 9 Mar 2012 15:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIKPjMM5gxZa for ; Fri, 9 Mar 2012 15:34:23 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id E95E721E8018 for ; Fri, 9 Mar 2012 15:34:22 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id jXzT1i0061YDfWL59baPMb; Fri, 09 Mar 2012 23:34:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id jbaN1i01e07duvL3gbaNL2; Fri, 09 Mar 2012 23:34:23 +0000 Message-ID: <4F5A937C.8080809@alum.mit.edu> Date: Fri, 09 Mar 2012 18:34:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Roni even References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:34:24 -0000 On 3/9/12 5:40 PM, Roni even wrote: > Mary, > > I have no problem with having just capture scene and taking out the > capture set. This is a very minor issue in the discussion. > > I hope we can have an agreed text on simultaneouscapabilitiesand capture > scene entries and how a consumer selects a configuration > > As for the MCU case you mention, my view is that this is not a CLUE > issue but a general MCU problem of source selection by participants and > you can see some discussion in draft-lennox-mmusic-sdp-source-selection-03 That sort of source selection works once the media is being sent to you. But I don't see how its helpful for decoding an advertisement and deciding what captures you want to receive. Or are you a tight coupling between that draft and CLUE, so that it provides the select functionality? Thanks, Paul > Roni Even > > ------------------------------------------------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary > Barnes [mary.ietf.barnes@gmail.com] > *Sent:* Friday, March 09, 2012 23:21 > *To:* Paul Kyzivat > *Cc:* clue@ietf.org > *Subject:* Re: [clue] Proposal to combine capture scene and capture set > > Paul, > > I'm trying to discern if we have consensus on the basic question of > whether people are okay with replacing the term "capture set" with > "capture scene" using the definitions that Mark has below. Paul, can you > please clarify two things for the WG: > 1) That you are speaking as an individual in the threads (i.e., you are > not trying to evaluate the thread for consensus) > 2) I *think* you are disagreeing with Mark's proposal, but that's not > clear to me. I think you are suggesting that "Capture Scene" be defined > to have a more information than just capture scene entries. Is that correct? > > Thanks, > Mary. > - as WG co-chair > > On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat > wrote: > > On 3/5/12 2:16 PM, Duckworth, Mark wrote: > > At the interim meeting, there was some support for combining the > concepts of “capture scene” and “capture set” into a single > concept. So > here is a rough proposal for doing that, essentially using the term > “capture scene” to replace the previous term “capture set”, and > eliminating the original separate capture scene concept. > > Definitions: > > *Capture Scene: a structure representing the scene that is > captured by a > collection of capture devices. A capture scene includes one or more > capture scene entries, with each entry including one or more media > captures. > > *Capture Scene Entry: a list of media captures of the same media > type > that together form one way to represent the capture scene. > > > One of the reasons I preferred "Capture Scene" to "Capture Set" is > that "set" implied to me that it is *only* a set of captures. But in > fact there are already other attributes in addition to the set of > captures (such as the purpose), and there will probably be more as > we proceed. > > To me, "Capture Scene Entry" conveys some of that same assumption. > Namely, that a Capture Scene" is made up of a number of Capture > Scene Entries, which seems to exclude other attributes that are not > Capture Scene Entries. > > It would feel more natural to me to have a Capture Set that is a set > of media captures. (That is, what was previously called a Capture > Set Entry.) And then define another term for a grouping of these > Capture Sets. I'm having trouble coming up with a term for that > which matches the intent well, but as a swag, how about Capture Set > Alternatives. > > So then you would have a logical structure something like: > > - Advertisement > - Capture Scene (one or more) > - Description > - Purpose > - Area of Scene > - Capture Set Alternatives (one or more) > - Capture Set (one or more) > - Capture > > I don't think Capture Set Alternatives is the right term. I think I > am hampered in finding a better term by not really having a crisp > understanding of the reason for having this grouping. Its partly > about alternatives in that there is an expectation that for a > particular medium you would choose only one. But its not about > alternatives in that you need to choose audio and video > independently. Also, that is only an approximation - there seem to > be expected cases when entries from more than one video entry would > be chosen. > > In my experience, when its hard to find a good term it usually means > that the thing being named is not sufficiently defined and likely > can be factored into more meaningful pieces. > > Thanks, > Paul > > Text for section 6.2 Capture Scene (was 6.2 Capture Set): > > A capture scene represents, for example, the video image of a > group of > people seated next to each other, along with the sound of their > voices, > which could be represented by some number of VCs and ACs in the > capture > scene entries. A middle box may also express capture scenes that it > constructs from media streams it receives. > > A media provider arranges media captures in a capture scene to > help the > media consumer choose which captures it wants. The capture scene > entries > in a capture scene are different alternatives the provider is > suggesting > for representing the capture scene. The media consumer can choose to > receive all media captures from one capture scene entry for each > media > type (e.g. audio and video), or it can pick and choose media > captures > regardless of how the provider arranges them in capture scene > entries. > > A capture scene may include more than one type of media. For > example, a > capture scene can include several capture scene entries for video > captures, and several capture scene entries for audio captures. > > (This text would be worked into section 6.2, not replace it > completely. > Other things in section 6.2 and elsewhere would need to be > edited to be > consistent with the new terminology in this proposal) > > Regards, > > Mark > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > From Mark.Duckworth@polycom.com Fri Mar 9 17:28:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECAA21E8069 for ; Fri, 9 Mar 2012 17:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.525 X-Spam-Level: X-Spam-Status: No, score=-6.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujAZqH6fs+cO for ; Fri, 9 Mar 2012 17:28:52 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id C203421E8053 for ; Fri, 9 Mar 2012 17:28:45 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 9 Mar 2012 17:28:44 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , Mary Barnes Date: Fri, 9 Mar 2012 17:28:41 -0800 Thread-Topic: [clue] Proposal to combine capture scene and capture set Thread-Index: Acz+QTLNz3PMzP5tQY+KEYmPYq9mDAAGd2Sg Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FB8402B2@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> <4F5A7F66.1070206@alum.mit.edu> In-Reply-To: <4F5A7F66.1070206@alum.mit.edu> 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 Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 01:28:53 -0000 Thanks Paul and Mary for re-focusing on the specific proposal. I agree the= re are still other issues regarding capture scenes, that we can continue to= discuss. So as the framework editor, I would like to hear from you as co-chairs whet= her or not I should update the document according to the proposal here: http://www.ietf.org/mail-archive/web/clue/current/msg01141.html If you say go ahead, I should be able to do it before the Monday deadline. Thanks, Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, March 09, 2012 5:09 PM > To: Mary Barnes > Cc: clue@ietf.org > Subject: Re: [clue] Proposal to combine capture scene and capture set >=20 > On 3/9/12 4:21 PM, Mary Barnes wrote: > > Paul, > > > > I'm trying to discern if we have consensus on the basic question of > > whether people are okay with replacing the term "capture set" with > > "capture scene" using the definitions that Mark has below. Paul, can > > you please clarify two things for the WG: > > 1) That you are speaking as an individual in the threads (i.e., you > > are not trying to evaluate the thread for consensus) >=20 > Sorry for not making it clear. I have indeed been speaking as an individu= al in > this discussion. >=20 > > 2) I *think* you are disagreeing with Mark's proposal, but that's not > > clear to me. I think you are suggesting that "Capture Scene" be > > defined to have a more information than just capture scene entries. > > Is that correct? >=20 > I very much am in favor of Capture Scene replacing Capture Set. > As far as I am concerned that can happen and we can continue to discuss t= he > nuances of what is in a Capture Scene. >=20 > Another related question was whether there can be more than one Capture > Scene per advertisement. But I think it has now been settled that there c= an. >=20 > The rest may be a tempest in a tea pot. I'm surprised there seems to be s= o > much controversy. Its about how many and what sort of Capture Scenes > might appear in an advertisement from an MCU. Of course we don't really > have to settle that now, or ever. I've been arguing that when there are > multiple Scenes in an advertisement there should be some added > attribute(s) available to help distinguish them. But we don't have to set= tle > that soon either. >=20 > Thanks, > Paul >=20 >=20 > > Thanks, > > Mary. > > - as WG co-chair > > > > On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat > > wrote: > > > > On 3/5/12 2:16 PM, Duckworth, Mark wrote: > > > > At the interim meeting, there was some support for combining th= e > > concepts of "capture scene" and "capture set" into a single > > concept. So > > here is a rough proposal for doing that, essentially using the = term > > "capture scene" to replace the previous term "capture set", and > > eliminating the original separate capture scene concept. > > > > Definitions: > > > > *Capture Scene: a structure representing the scene that is > > captured by a > > collection of capture devices. A capture scene includes one or = more > > capture scene entries, with each entry including one or more me= dia > > captures. > > > > *Capture Scene Entry: a list of media captures of the same medi= a > > type > > that together form one way to represent the capture scene. > > > > > > One of the reasons I preferred "Capture Scene" to "Capture Set" is > > that "set" implied to me that it is *only* a set of captures. But i= n > > fact there are already other attributes in addition to the set of > > captures (such as the purpose), and there will probably be more as > > we proceed. > > > > To me, "Capture Scene Entry" conveys some of that same assumption. > > Namely, that a Capture Scene" is made up of a number of Capture > > Scene Entries, which seems to exclude other attributes that are not > > Capture Scene Entries. > > > > It would feel more natural to me to have a Capture Set that is a se= t > > of media captures. (That is, what was previously called a Capture > > Set Entry.) And then define another term for a grouping of these > > Capture Sets. I'm having trouble coming up with a term for that > > which matches the intent well, but as a swag, how about Capture Set > > Alternatives. > > > > So then you would have a logical structure something like: > > > > - Advertisement > > - Capture Scene (one or more) > > - Description > > - Purpose > > - Area of Scene > > - Capture Set Alternatives (one or more) > > - Capture Set (one or more) > > - Capture > > > > I don't think Capture Set Alternatives is the right term. I think I > > am hampered in finding a better term by not really having a crisp > > understanding of the reason for having this grouping. Its partly > > about alternatives in that there is an expectation that for a > > particular medium you would choose only one. But its not about > > alternatives in that you need to choose audio and video > > independently. Also, that is only an approximation - there seem to > > be expected cases when entries from more than one video entry would > > be chosen. > > > > In my experience, when its hard to find a good term it usually mean= s > > that the thing being named is not sufficiently defined and likely > > can be factored into more meaningful pieces. > > > > Thanks, > > Paul > > > > Text for section 6.2 Capture Scene (was 6.2 Capture Set): > > > > A capture scene represents, for example, the video image of a > > group of > > people seated next to each other, along with the sound of their > > voices, > > which could be represented by some number of VCs and ACs in the > > capture > > scene entries. A middle box may also express capture scenes tha= t it > > constructs from media streams it receives. > > > > A media provider arranges media captures in a capture scene to > > help the > > media consumer choose which captures it wants. The capture scen= e > > entries > > in a capture scene are different alternatives the provider is > > suggesting > > for representing the capture scene. The media consumer can choo= se to > > receive all media captures from one capture scene entry for eac= h > > media > > type (e.g. audio and video), or it can pick and choose media > > captures > > regardless of how the provider arranges them in capture scene > > entries. > > > > A capture scene may include more than one type of media. For > > example, a > > capture scene can include several capture scene entries for vid= eo > > captures, and several capture scene entries for audio captures. > > > > (This text would be worked into section 6.2, not replace it > > completely. > > Other things in section 6.2 and elsewhere would need to be > > edited to be > > consistent with the new terminology in this proposal) > > > > Regards, > > > > Mark > > > > > > > > _________________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > > > > > > > _________________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Mar 9 17:50:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F37021E8039 for ; Fri, 9 Mar 2012 17:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5I-3RsKzAoL for ; Fri, 9 Mar 2012 17:50:48 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id E945321E8018 for ; Fri, 9 Mar 2012 17:50:47 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id jbQ91i0061YDfWL58dqoei; Sat, 10 Mar 2012 01:50:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id jdqo1i00H07duvL3gdqoCj; Sat, 10 Mar 2012 01:50:48 +0000 Message-ID: <4F5AB376.3060808@alum.mit.edu> Date: Fri, 09 Mar 2012 20:50:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Duckworth, Mark" References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> <4F5A7F66.1070206@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB8402B2@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB8402B2@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 01:50:49 -0000 On 3/9/12 8:28 PM, Duckworth, Mark wrote: > Thanks Paul and Mary for re-focusing on the specific proposal. I agree there are still other issues regarding capture scenes, that we can continue to discuss. > > So as the framework editor, I would like to hear from you as co-chairs whether or not I should update the document according to the proposal here: > http://www.ietf.org/mail-archive/web/clue/current/msg01141.html I think you should go ahead with this. Lets see if Mary agrees. Thanks, Paul > If you say go ahead, I should be able to do it before the Monday deadline. > > Thanks, > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Friday, March 09, 2012 5:09 PM >> To: Mary Barnes >> Cc: clue@ietf.org >> Subject: Re: [clue] Proposal to combine capture scene and capture set >> >> On 3/9/12 4:21 PM, Mary Barnes wrote: >>> Paul, >>> >>> I'm trying to discern if we have consensus on the basic question of >>> whether people are okay with replacing the term "capture set" with >>> "capture scene" using the definitions that Mark has below. Paul, can >>> you please clarify two things for the WG: >>> 1) That you are speaking as an individual in the threads (i.e., you >>> are not trying to evaluate the thread for consensus) >> >> Sorry for not making it clear. I have indeed been speaking as an individual in >> this discussion. >> >>> 2) I *think* you are disagreeing with Mark's proposal, but that's not >>> clear to me. I think you are suggesting that "Capture Scene" be >>> defined to have a more information than just capture scene entries. >>> Is that correct? >> >> I very much am in favor of Capture Scene replacing Capture Set. >> As far as I am concerned that can happen and we can continue to discuss the >> nuances of what is in a Capture Scene. >> >> Another related question was whether there can be more than one Capture >> Scene per advertisement. But I think it has now been settled that there can. >> >> The rest may be a tempest in a tea pot. I'm surprised there seems to be so >> much controversy. Its about how many and what sort of Capture Scenes >> might appear in an advertisement from an MCU. Of course we don't really >> have to settle that now, or ever. I've been arguing that when there are >> multiple Scenes in an advertisement there should be some added >> attribute(s) available to help distinguish them. But we don't have to settle >> that soon either. >> >> Thanks, >> Paul >> >> >>> Thanks, >>> Mary. >>> - as WG co-chair >>> >>> On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat>> > wrote: >>> >>> On 3/5/12 2:16 PM, Duckworth, Mark wrote: >>> >>> At the interim meeting, there was some support for combining the >>> concepts of "capture scene" and "capture set" into a single >>> concept. So >>> here is a rough proposal for doing that, essentially using the term >>> "capture scene" to replace the previous term "capture set", and >>> eliminating the original separate capture scene concept. >>> >>> Definitions: >>> >>> *Capture Scene: a structure representing the scene that is >>> captured by a >>> collection of capture devices. A capture scene includes one or more >>> capture scene entries, with each entry including one or more media >>> captures. >>> >>> *Capture Scene Entry: a list of media captures of the same media >>> type >>> that together form one way to represent the capture scene. >>> >>> >>> One of the reasons I preferred "Capture Scene" to "Capture Set" is >>> that "set" implied to me that it is *only* a set of captures. But in >>> fact there are already other attributes in addition to the set of >>> captures (such as the purpose), and there will probably be more as >>> we proceed. >>> >>> To me, "Capture Scene Entry" conveys some of that same assumption. >>> Namely, that a Capture Scene" is made up of a number of Capture >>> Scene Entries, which seems to exclude other attributes that are not >>> Capture Scene Entries. >>> >>> It would feel more natural to me to have a Capture Set that is a set >>> of media captures. (That is, what was previously called a Capture >>> Set Entry.) And then define another term for a grouping of these >>> Capture Sets. I'm having trouble coming up with a term for that >>> which matches the intent well, but as a swag, how about Capture Set >>> Alternatives. >>> >>> So then you would have a logical structure something like: >>> >>> - Advertisement >>> - Capture Scene (one or more) >>> - Description >>> - Purpose >>> - Area of Scene >>> - Capture Set Alternatives (one or more) >>> - Capture Set (one or more) >>> - Capture >>> >>> I don't think Capture Set Alternatives is the right term. I think I >>> am hampered in finding a better term by not really having a crisp >>> understanding of the reason for having this grouping. Its partly >>> about alternatives in that there is an expectation that for a >>> particular medium you would choose only one. But its not about >>> alternatives in that you need to choose audio and video >>> independently. Also, that is only an approximation - there seem to >>> be expected cases when entries from more than one video entry would >>> be chosen. >>> >>> In my experience, when its hard to find a good term it usually means >>> that the thing being named is not sufficiently defined and likely >>> can be factored into more meaningful pieces. >>> >>> Thanks, >>> Paul >>> >>> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >>> >>> A capture scene represents, for example, the video image of a >>> group of >>> people seated next to each other, along with the sound of their >>> voices, >>> which could be represented by some number of VCs and ACs in the >>> capture >>> scene entries. A middle box may also express capture scenes that it >>> constructs from media streams it receives. >>> >>> A media provider arranges media captures in a capture scene to >>> help the >>> media consumer choose which captures it wants. The capture scene >>> entries >>> in a capture scene are different alternatives the provider is >>> suggesting >>> for representing the capture scene. The media consumer can choose to >>> receive all media captures from one capture scene entry for each >>> media >>> type (e.g. audio and video), or it can pick and choose media >>> captures >>> regardless of how the provider arranges them in capture scene >>> entries. >>> >>> A capture scene may include more than one type of media. For >>> example, a >>> capture scene can include several capture scene entries for video >>> captures, and several capture scene entries for audio captures. >>> >>> (This text would be worked into section 6.2, not replace it >>> completely. >>> Other things in section 6.2 and elsewhere would need to be >>> edited to be >>> consistent with the new terminology in this proposal) >>> >>> Regards, >>> >>> Mark >>> >>> >>> >>> _________________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/__listinfo/clue >>> >>> >>> >>> _________________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/__listinfo/clue >>> >>> >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Sat Mar 10 11:44:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403FE21F8508 for ; Sat, 10 Mar 2012 11:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.683 X-Spam-Level: X-Spam-Status: No, score=-102.683 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHpVZiEv8M34 for ; Sat, 10 Mar 2012 11:44:25 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2097421F8514 for ; Sat, 10 Mar 2012 11:44:23 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so3174605vcb.31 for ; Sat, 10 Mar 2012 11:44:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4DioHzTAmJAcOuHnyZBMEOHstyKdGgCRx5vDnO2P+nw=; b=VMQszPuuigsKuQ254HZfUtNSjY0KbV4yB4kHdl2qVf8I3w3P5/cR4wZr9OtfjZrL0v Qumk2kn9ZgKtBzp338n8iOCI0bTOVjeHIk+2PSCNcaApS3iMhmSCYG8TFy+no3v/V6Gy COPBtWNq0wV5Lgh1NowbpgW+jwZhhBsOwhTWt3or9TVME7xY9bT2REz4p78X/hhwyDrp 2d+0g9c031bfEoCfJjLoDUwexUjDn3T0rs9o0FK31gS/ncxbOkctnTGvc0Dcuz779JbY i6UOQ/Rp1txUCcg5ExXRL82OMDv8XAsHnUPLnmYZJV/i/UeJxSrEQoZoHh4cOGFgHwmD uv5g== MIME-Version: 1.0 Received: by 10.52.90.178 with SMTP id bx18mr10338104vdb.123.1331408656638; Sat, 10 Mar 2012 11:44:16 -0800 (PST) Received: by 10.52.111.136 with HTTP; Sat, 10 Mar 2012 11:44:16 -0800 (PST) In-Reply-To: <4F5AB376.3060808@alum.mit.edu> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <4F567412.7090506@alum.mit.edu> <4F5A7F66.1070206@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FB8402B2@CRPMBOXPRD01.polycom.com> <4F5AB376.3060808@alum.mit.edu> Date: Sat, 10 Mar 2012 13:44:16 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf3071cffa07a46f04bae8bc5d Cc: "clue@ietf.org" Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 19:44:26 -0000 --20cf3071cffa07a46f04bae8bc5d Content-Type: text/plain; charset=ISO-8859-1 Yes, I agree. Thanks, Mary. On Fri, Mar 9, 2012 at 7:50 PM, Paul Kyzivat wrote: > On 3/9/12 8:28 PM, Duckworth, Mark wrote: > >> Thanks Paul and Mary for re-focusing on the specific proposal. I agree >> there are still other issues regarding capture scenes, that we can continue >> to discuss. >> >> So as the framework editor, I would like to hear from you as co-chairs >> whether or not I should update the document according to the proposal here: >> http://www.ietf.org/mail-**archive/web/clue/current/**msg01141.html >> > > I think you should go ahead with this. Lets see if Mary agrees. > > Thanks, > Paul > > > If you say go ahead, I should be able to do it before the Monday deadline. >> >> Thanks, >> Mark >> >> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>> Paul Kyzivat >>> Sent: Friday, March 09, 2012 5:09 PM >>> To: Mary Barnes >>> Cc: clue@ietf.org >>> Subject: Re: [clue] Proposal to combine capture scene and capture set >>> >>> On 3/9/12 4:21 PM, Mary Barnes wrote: >>> >>>> Paul, >>>> >>>> I'm trying to discern if we have consensus on the basic question of >>>> whether people are okay with replacing the term "capture set" with >>>> "capture scene" using the definitions that Mark has below. Paul, can >>>> you please clarify two things for the WG: >>>> 1) That you are speaking as an individual in the threads (i.e., you >>>> are not trying to evaluate the thread for consensus) >>>> >>> >>> Sorry for not making it clear. I have indeed been speaking as an >>> individual in >>> this discussion. >>> >>> 2) I *think* you are disagreeing with Mark's proposal, but that's not >>>> clear to me. I think you are suggesting that "Capture Scene" be >>>> defined to have a more information than just capture scene entries. >>>> Is that correct? >>>> >>> >>> I very much am in favor of Capture Scene replacing Capture Set. >>> As far as I am concerned that can happen and we can continue to discuss >>> the >>> nuances of what is in a Capture Scene. >>> >>> Another related question was whether there can be more than one Capture >>> Scene per advertisement. But I think it has now been settled that there >>> can. >>> >>> The rest may be a tempest in a tea pot. I'm surprised there seems to be >>> so >>> much controversy. Its about how many and what sort of Capture Scenes >>> might appear in an advertisement from an MCU. Of course we don't really >>> have to settle that now, or ever. I've been arguing that when there are >>> multiple Scenes in an advertisement there should be some added >>> attribute(s) available to help distinguish them. But we don't have to >>> settle >>> that soon either. >>> >>> Thanks, >>> Paul >>> >>> >>> Thanks, >>>> Mary. >>>> - as WG co-chair >>>> >>>> On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat>>> **> wrote: >>>> >>>> On 3/5/12 2:16 PM, Duckworth, Mark wrote: >>>> >>>> At the interim meeting, there was some support for combining the >>>> concepts of "capture scene" and "capture set" into a single >>>> concept. So >>>> here is a rough proposal for doing that, essentially using the >>>> term >>>> "capture scene" to replace the previous term "capture set", and >>>> eliminating the original separate capture scene concept. >>>> >>>> Definitions: >>>> >>>> *Capture Scene: a structure representing the scene that is >>>> captured by a >>>> collection of capture devices. A capture scene includes one or >>>> more >>>> capture scene entries, with each entry including one or more >>>> media >>>> captures. >>>> >>>> *Capture Scene Entry: a list of media captures of the same media >>>> type >>>> that together form one way to represent the capture scene. >>>> >>>> >>>> One of the reasons I preferred "Capture Scene" to "Capture Set" is >>>> that "set" implied to me that it is *only* a set of captures. But in >>>> fact there are already other attributes in addition to the set of >>>> captures (such as the purpose), and there will probably be more as >>>> we proceed. >>>> >>>> To me, "Capture Scene Entry" conveys some of that same assumption. >>>> Namely, that a Capture Scene" is made up of a number of Capture >>>> Scene Entries, which seems to exclude other attributes that are not >>>> Capture Scene Entries. >>>> >>>> It would feel more natural to me to have a Capture Set that is a set >>>> of media captures. (That is, what was previously called a Capture >>>> Set Entry.) And then define another term for a grouping of these >>>> Capture Sets. I'm having trouble coming up with a term for that >>>> which matches the intent well, but as a swag, how about Capture Set >>>> Alternatives. >>>> >>>> So then you would have a logical structure something like: >>>> >>>> - Advertisement >>>> - Capture Scene (one or more) >>>> - Description >>>> - Purpose >>>> - Area of Scene >>>> - Capture Set Alternatives (one or more) >>>> - Capture Set (one or more) >>>> - Capture >>>> >>>> I don't think Capture Set Alternatives is the right term. I think I >>>> am hampered in finding a better term by not really having a crisp >>>> understanding of the reason for having this grouping. Its partly >>>> about alternatives in that there is an expectation that for a >>>> particular medium you would choose only one. But its not about >>>> alternatives in that you need to choose audio and video >>>> independently. Also, that is only an approximation - there seem to >>>> be expected cases when entries from more than one video entry would >>>> be chosen. >>>> >>>> In my experience, when its hard to find a good term it usually means >>>> that the thing being named is not sufficiently defined and likely >>>> can be factored into more meaningful pieces. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Text for section 6.2 Capture Scene (was 6.2 Capture Set): >>>> >>>> A capture scene represents, for example, the video image of a >>>> group of >>>> people seated next to each other, along with the sound of their >>>> voices, >>>> which could be represented by some number of VCs and ACs in the >>>> capture >>>> scene entries. A middle box may also express capture scenes >>>> that it >>>> constructs from media streams it receives. >>>> >>>> A media provider arranges media captures in a capture scene to >>>> help the >>>> media consumer choose which captures it wants. The capture scene >>>> entries >>>> in a capture scene are different alternatives the provider is >>>> suggesting >>>> for representing the capture scene. The media consumer can >>>> choose to >>>> receive all media captures from one capture scene entry for each >>>> media >>>> type (e.g. audio and video), or it can pick and choose media >>>> captures >>>> regardless of how the provider arranges them in capture scene >>>> entries. >>>> >>>> A capture scene may include more than one type of media. For >>>> example, a >>>> capture scene can include several capture scene entries for >>>> video >>>> captures, and several capture scene entries for audio captures. >>>> >>>> (This text would be worked into section 6.2, not replace it >>>> completely. >>>> Other things in section 6.2 and elsewhere would need to be >>>> edited to be >>>> consistent with the new terminology in this proposal) >>>> >>>> Regards, >>>> >>>> Mark >>>> >>>> >>>> >>>> ______________________________**___________________ >>>> clue mailing list >>>> clue@ietf.org> >>>> https://www.ietf.org/mailman/_**_listinfo/clue >>>> >>>> > >>>> >>>> >>>> ______________________________**___________________ >>>> clue mailing list >>>> clue@ietf.org> >>>> https://www.ietf.org/mailman/_**_listinfo/clue >>>> >>>> > >>>> >>>> >>>> >>> ______________________________**_________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/**listinfo/clue >>> >> >> > --20cf3071cffa07a46f04bae8bc5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I agree.

Thanks,
Mary.

On Fri, Mar 9, 2012 at 7:50 PM, Paul Kyzivat <pkyzivat@alum.mit.edu= > wrote:
On 3/9/12 8:28 PM, Duckwor= th, Mark wrote:
Thanks Paul and Mary for re-focusing on the specific proposal. =A0I agree t= here are still other issues regarding capture scenes, that we can continue = to discuss.

So as the framework editor, I would like to hear from you as co-chairs whet= her or not I should update the document according to the proposal here:
http://www.ietf.org/mail-archive/web/clue/current= /msg01141.html

I think you should go ahead with this. Lets see if Mary agrees.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


If you say go ahead, I should be able to do it before the Monday deadline.<= br>
Thanks,
Mark

-----Original Message-----
From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
Paul Kyzivat
Sent: Friday, March 09, 2012 5:09 PM
To: Mary Barnes
Cc: clue@ietf.org Subject: Re: [clue] Proposal to combine capture scene and capture set

On 3/9/12 4:21 PM, Mary Barnes wrote:
Paul,

I'm trying to discern if we have consensus on the basic question of
whether people are okay with replacing the term "capture set" wit= h
"capture scene" using the definitions that Mark has below. =A0 = =A0Paul, can
you please clarify two things for the WG:
1) That you are speaking as an individual in the threads (i.e., you
are not trying to evaluate the thread for consensus)

Sorry for not making it clear. I have indeed been speaking as an individual= in
this discussion.

2) =A0I *think* you are disagreeing with Mark's proposal, but that'= s not
clear to me. =A0I think you are suggesting that "Capture Scene" b= e
defined to have a more information than just capture scene entries.
Is that correct?

I very much am in favor of Capture Scene replacing Capture Set.
As far as I am concerned that can happen and we can continue to discuss the=
nuances of what is in a Capture Scene.

Another related question was whether there can be more than one Capture
Scene per advertisement. But I think it has now been settled that there can= .

The rest may be a tempest in a tea pot. I'm surprised there seems to be= so
much controversy. Its about how many and what sort of Capture Scenes
might appear in an advertisement from an MCU. Of course we don't really=
have to settle that now, or ever. I've been arguing that when there are=
multiple Scenes in an advertisement there should be some added
attribute(s) available to help distinguish them. But we don't have to s= ettle
that soon either.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


Thanks,
Mary.
- as WG co-chair

On Tue, Mar 6, 2012 at 2:31 PM, Paul Kyzivat<pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> =A0wrote:

=A0 =A0 On 3/5/12 2:16 PM, Duckworth, Mark wrote:

=A0 =A0 =A0 =A0 At the interim meeting, there was some support for combini= ng the
=A0 =A0 =A0 =A0 concepts of "capture scene" and "capture se= t" into a single
=A0 =A0 =A0 =A0 concept. So
=A0 =A0 =A0 =A0 here is a rough proposal for doing that, essentially using= the term
=A0 =A0 =A0 =A0 "capture scene" to replace the previous term &qu= ot;capture set", and
=A0 =A0 =A0 =A0 eliminating the original separate capture scene concept.
=A0 =A0 =A0 =A0 Definitions:

=A0 =A0 =A0 =A0 *Capture Scene: a structure representing the scene that is=
=A0 =A0 =A0 =A0 captured by a
=A0 =A0 =A0 =A0 collection of capture devices. A capture scene includes on= e or more
=A0 =A0 =A0 =A0 capture scene entries, with each entry including one or mo= re media
=A0 =A0 =A0 =A0 captures.

=A0 =A0 =A0 =A0 *Capture Scene Entry: a list of media captures of the same= media
=A0 =A0 =A0 =A0 type
=A0 =A0 =A0 =A0 that together form one way to represent the capture scene.=


=A0 =A0 One of the reasons I preferred "Capture Scene" to "= Capture Set" is
=A0 =A0 that "set" implied to me that it is *only* a set of capt= ures. But in
=A0 =A0 fact there are already other attributes in addition to the set of<= br> =A0 =A0 captures (such as the purpose), and there will probably be more as=
=A0 =A0 we proceed.

=A0 =A0 To me, "Capture Scene Entry" conveys some of that same a= ssumption.
=A0 =A0 Namely, that a Capture Scene" is made up of a number of Captu= re
=A0 =A0 Scene Entries, which seems to exclude other attributes that are no= t
=A0 =A0 Capture Scene Entries.

=A0 =A0 It would feel more natural to me to have a Capture Set that is a s= et
=A0 =A0 of media captures. (That is, what was previously called a Capture<= br> =A0 =A0 Set Entry.) And then define another term for a grouping of these =A0 =A0 Capture Sets. I'm having trouble coming up with a term for tha= t
=A0 =A0 which matches the intent well, but as a swag, how about Capture Se= t
=A0 =A0 Alternatives.

=A0 =A0 So then you would have a logical structure something like:

=A0 =A0 - Advertisement
=A0 =A0 =A0 - Capture Scene (one or more)
=A0 =A0 =A0 =A0 - Description
=A0 =A0 =A0 =A0 - Purpose
=A0 =A0 =A0 =A0 - Area of Scene
=A0 =A0 =A0 =A0 - Capture Set Alternatives (one or more)
=A0 =A0 =A0 =A0 =A0 - Capture Set (one or more)
=A0 =A0 =A0 =A0 =A0 =A0 - Capture

=A0 =A0 I don't think Capture Set Alternatives is the right term. I th= ink I
=A0 =A0 am hampered in finding a better term by not really having a crisp<= br> =A0 =A0 understanding of the reason for having this grouping. Its partly =A0 =A0 about alternatives in that there is an expectation that for a
=A0 =A0 particular medium you would choose only one. But its not about
=A0 =A0 alternatives in that you need to choose audio and video
=A0 =A0 independently. Also, that is only an approximation - there seem to=
=A0 =A0 be expected cases when entries from more than one video entry woul= d
=A0 =A0 be chosen.

=A0 =A0 In my experience, when its hard to find a good term it usually mea= ns
=A0 =A0 that the thing being named is not sufficiently defined and likely<= br> =A0 =A0 can be factored into more meaningful pieces.

=A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 Paul

=A0 =A0 =A0 =A0 Text for section 6.2 Capture Scene (was 6.2 Capture Set):<= br>
=A0 =A0 =A0 =A0 A capture scene represents, for example, the video image o= f a
=A0 =A0 =A0 =A0 group of
=A0 =A0 =A0 =A0 people seated next to each other, along with the sound of = their
=A0 =A0 =A0 =A0 voices,
=A0 =A0 =A0 =A0 which could be represented by some number of VCs and ACs i= n the
=A0 =A0 =A0 =A0 capture
=A0 =A0 =A0 =A0 scene entries. A middle box may also express capture scene= s that it
=A0 =A0 =A0 =A0 constructs from media streams it receives.

=A0 =A0 =A0 =A0 A media provider arranges media captures in a capture scen= e to
=A0 =A0 =A0 =A0 help the
=A0 =A0 =A0 =A0 media consumer choose which captures it wants. The capture= scene
=A0 =A0 =A0 =A0 entries
=A0 =A0 =A0 =A0 in a capture scene are different alternatives the provider= is
=A0 =A0 =A0 =A0 suggesting
=A0 =A0 =A0 =A0 for representing the capture scene. The media consumer can= choose to
=A0 =A0 =A0 =A0 receive all media captures from one capture scene entry fo= r each
=A0 =A0 =A0 =A0 media
=A0 =A0 =A0 =A0 type (e.g. audio and video), or it can pick and choose med= ia
=A0 =A0 =A0 =A0 captures
=A0 =A0 =A0 =A0 regardless of how the provider arranges them in capture sc= ene
=A0 =A0 =A0 =A0 entries.

=A0 =A0 =A0 =A0 A capture scene may include more than one type of media. F= or
=A0 =A0 =A0 =A0 example, a
=A0 =A0 =A0 =A0 capture scene can include several capture scene entries fo= r video
=A0 =A0 =A0 =A0 captures, and several capture scene entries for audio capt= ures.

=A0 =A0 =A0 =A0 (This text would be worked into section 6.2, not replace i= t
=A0 =A0 =A0 =A0 completely.
=A0 =A0 =A0 =A0 Other things in section 6.2 and elsewhere would need to be=
=A0 =A0 =A0 =A0 edited to be
=A0 =A0 =A0 =A0 consistent with the new terminology in this proposal)

=A0 =A0 =A0 =A0 Regards,

=A0 =A0 =A0 =A0 Mark



=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 clue@ie= tf.org<mailto:clu= e@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>= ;


=A0 =A0 _________________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org<mailto:clue@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>



_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue



--20cf3071cffa07a46f04bae8bc5d-- From Even.roni@huawei.com Mon Mar 12 02:33:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B927721F8638 for ; Mon, 12 Mar 2012 02:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHGEV7afhHi3 for ; Mon, 12 Mar 2012 02:33:58 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 69A6321F8478 for ; Mon, 12 Mar 2012 02:33:57 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00JH4M9TGR@szxga05-in.huawei.com> for clue@ietf.org; Mon, 12 Mar 2012 17:27:29 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R001ACM9OJF@szxga05-in.huawei.com> for clue@ietf.org; Mon, 12 Mar 2012 17:27:24 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHT61437; Mon, 12 Mar 2012 17:26:38 +0800 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 17:26:00 +0800 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.13]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Mon, 12 Mar 2012 17:26:29 +0800 Date: Mon, 12 Mar 2012 09:26:29 +0000 From: Roni even In-reply-to: <20120312092050.9642.52271.idtracker@ietfa.amsl.com> X-Originating-IP: [172.24.1.70] To: "clue@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-even-clue-rtp-mapping-01.txt Thread-index: AQHNADF6mKbq3HV1o0Wviqx2mUBKH5ZmYr1a X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120312092050.9642.52271.idtracker@ietfa.amsl.com> Subject: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 09:33:58 -0000 Hi, I updated the draft that I submitted before the interim meeting Roni ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, March 12, 2012 11:20 To: Roni even Subject: New Version Notification for draft-even-clue-rtp-mapping-01.txt A new version of I-D, draft-even-clue-rtp-mapping-01.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-clue-rtp-mapping Revision: 01 Title: Mapping RTP streams to CLUE media captures Creation date: 2012-03-12 WG ID: Individual Submission Number of pages: 9 Abstract: This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. The IETF Secretariat From pkyzivat@alum.mit.edu Mon Mar 12 08:10:11 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57E121F87A0 for ; Mon, 12 Mar 2012 08:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kr936Dxw-UME for ; Mon, 12 Mar 2012 08:10:10 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9A80021F879E for ; Mon, 12 Mar 2012 08:10:10 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id kf0d1i0080ldTLk5DfABs9; Mon, 12 Mar 2012 15:10:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta04.westchester.pa.mail.comcast.net with comcast id kfAA1i00X07duvL3QfABoe; Mon, 12 Mar 2012 15:10:11 +0000 Message-ID: <4F5E11D1.8090401@alum.mit.edu> Date: Mon, 12 Mar 2012 11:10:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C8008@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FB790BAF@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FB790BAF@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Proposal to combine capture scene and capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:10:11 -0000 On 3/8/12 3:58 PM, Duckworth, Mark wrote: > The capture scene can be constructed by either the media provider or the > media consumer. > > */[Duckworth, Mark] No, the media provider constructs capture scenes, > which it includes in the provider advertisement it sends to the consumer./* > > That last point seems to be implied by "provider arranges" and "consumer > can choose" but would be good to verify. > > */[Duckworth, Mark] The consumer can choose from among various things > the provider advertises, but the consumer does not construct a capture > scene out of this./* Well, an MCU is a consumer of scenes from the endpoints attached to it. And it can then construct new scenes from the media received from them. But I don't think this was the point Mike was trying to make. Thanks, Paul From pkyzivat@alum.mit.edu Mon Mar 12 09:44:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C3821F87BF for ; Mon, 12 Mar 2012 09:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKBVYGe-syTC for ; Mon, 12 Mar 2012 09:44:44 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 80E7921F87BE for ; Mon, 12 Mar 2012 09:44:44 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id kgj21i0060cZkys54gkkoh; Mon, 12 Mar 2012 16:44:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id kgkk1i00u07duvL3Wgkk1f; Mon, 12 Mar 2012 16:44:44 +0000 Message-ID: <4F5E27FB.8080206@alum.mit.edu> Date: Mon, 12 Mar 2012 12:44:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <20120312092050.9642.52271.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:44:45 -0000 Roni, IIUC, you are proposing that the initial offer from an MCU would include the RTP streams required for all of the MCs it is advertising. Is that right? And each such stream would call for the maximum bandwidth required by any MC mapped to that stream? That might be excessive if the other end ultimately selects fewer MCs. (Whether those are significant issues can be discussed later.) I also don't understand how the mapping of MCs to m-lines via RTP-id works once you consider that both ends are sending media. After the o/a exchange there must be a single set of m-lines. According to RF5888, the mid value in the affer MUST be the same as the mid value in the answer. That means the answerer can't insert its own mid values corresponding to its RTP-id values. Also, the m-lines in the answer are constrained by the m-lines in the offer. The only fix I see for this is to first exchange advertisements (and maybe selections too), then compute a set of m-lines that are sufficient to handle the bidirectional exchange of MCs, and then exchange an o/a for that. Maybe there is another way. In any case I think this needs to be addressed in the draft. Thanks, Paul (as individual) From ron.even.tlv@gmail.com Mon Mar 12 13:25:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7D811E8086 for ; Mon, 12 Mar 2012 13:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9cjeFhXeTAO for ; Mon, 12 Mar 2012 13:25:02 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9D2911E8075 for ; Mon, 12 Mar 2012 13:25:01 -0700 (PDT) Received: by werb10 with SMTP id b10so4578852wer.31 for ; Mon, 12 Mar 2012 13:25:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=xKwKT2lHgfqVrzJU9pOfztFluCsBo99EoV7qSTsgsK4=; b=QUSI/fZAL4G62/MBTvFqzOBJcsi5BFYkkbLKVDnyNTIc5+gJJss+yP47rHG+HLEmuT qASOkNtkP3cjh2VJv3u/qaRiSpCK2EdxVHjGUrzzeDhO0khTEF2zAzR5XF2jd/7Mo6GR igf39277U6Os3m8XlMKIBWIkLhgktlVD7SF+RDP87Y0gqBQE7H7njtY7pt93M6pw4Lip QywHMTYJqg9c+RHF3VNADvgLHmVgB+C+0zB/ujGio6Vm7C0+NuduYVn0+hWczVQ4jCe5 21M7b+sxNdtZFvfaGCT1DwZYyffwokDx0MXrf6rz/sT9s9Ikw8yXiLnmTDJQ1CYg13EE 8MZg== Received: by 10.180.87.8 with SMTP id t8mr978594wiz.15.1331583900870; Mon, 12 Mar 2012 13:25:00 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id gg2sm53249902wib.7.2012.03.12.13.24.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 13:24:59 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <20120312092050.9642.52271.idtracker@ietfa.amsl.com> <4F5E27FB.8080206@alum.mit.edu> In-Reply-To: <4F5E27FB.8080206@alum.mit.edu> Date: Mon, 12 Mar 2012 22:24:09 +0200 Message-ID: <4f5e5b9b.c268b40a.5ce2.7d2f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Ab3GMwj3XGp1kRT2k8YDAx6a7owAEv2Aw Content-Language: en-us Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:25:03 -0000 Hi Paul, I think that the major focus is point to point but see inline Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, March 12, 2012 6:45 PM > To: clue@ietf.org > Subject: Re: [clue] FW: New Version Notification for draft-even-clue- > rtp-mapping-01.txt > > Roni, > > IIUC, you are proposing that the initial offer from an MCU would > include the RTP streams required for all of the MCs it is advertising. > Is that right? Roni: the initial offer should include RTP stream for the simultaneous Media capture that the endpoint specified (for example there is no need to have a separate m-line for a media capture coming from the same camera but offering different view like zoom out and zoom in view). The m-line provide information about the encoder which is a physical entity that in CLUE can be used to provide different content that is defined by the CLUE protocol. If it is an MCU it is an application decision what is the simultaneous set it wants to distribute. My view is that it is what you also called a "virtual room" that describes a common set for a conference that the MCU wants to use, the MCU has also physical encoder constrains similar to an end point. > > And each such stream would call for the maximum bandwidth required by > any MC mapped to that stream? Roni: I assume that you are asking about MCU case. If the conference is not transcoding the MCU will offer to the participants the bw of the common mode which is likely to be the minimum of all participants. BTW: this is not a CLUE issue it applies to any MCU that does non transcoded video conferences > > That might be excessive if the other end ultimately selects fewer MCs. > Roni: the bw is per m-line (using b=TIAS:) and per the SDP session (using b=AS: so if it uses less m-lines than less bw will be used as long as the total is less than the SDP session bw parameter. > (Whether those are significant issues can be discussed later.) > > I also don't understand how the mapping of MCs to m-lines via RTP-id > works once you consider that both ends are sending media. After the o/a > exchange there must be a single set of m-lines. According to RF5888, > the mid value in the affer MUST be the same as the mid value in the > answer. > That means the answerer can't insert its own mid values corresponding > to its RTP-id values. Also, the m-lines in the answer are constrained > by the m-lines in the offer. > > The only fix I see for this is to first exchange advertisements (and > maybe selections too), then compute a set of m-lines that are > sufficient to handle the bidirectional exchange of MCs, and then > exchange an o/a for that. Roni: this is a good point and I will need to address it. Your proposal is one option. I think that even of offering a full set in the initial offer it is based on what the offerer can send and receive using sendonly and recvonly attribute if it has different encoding and decoding resources. If the offer for example has three screens and cameras and the answer have one screen one camera and decode more than one stream it can either use recvonly attribute or after responding to the offer start a second offer/answer exchange to addree the asymmetry. CLUE also need two exchanges requiring advertisements from both sides. I assume this is the limitation of RFC3264 and SDP while if using H.245 you specify receive and transmit capabilities (maybe use H.245 for CLUE) > Maybe there is another way. In any case I think this needs to be > addressed in the draft. > > Thanks, > Paul (as individual) > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From internet-drafts@ietf.org Mon Mar 12 14:35:00 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2AB21F8923; Mon, 12 Mar 2012 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2Pcsj6tOEFB; Mon, 12 Mar 2012 14:35:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4721F88FA; Mon, 12 Mar 2012 14:35:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312213500.22273.62133.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:35:00 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:35:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Allyn Romanow Mark Duckworth Andrew Pepperell Brian Baldino Filename : draft-ietf-clue-framework-04.txt Pages : 35 Date : 2012-03-12 This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-framework-04.txt From Mark.Duckworth@polycom.com Mon Mar 12 14:37:32 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E5511E815F for ; Mon, 12 Mar 2012 14:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8aq9cqOjjm1 for ; Mon, 12 Mar 2012 14:37:31 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB4511E8159 for ; Mon, 12 Mar 2012 14:37:31 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 12 Mar 2012 14:37:30 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 12 Mar 2012 14:37:28 -0700 Thread-Topic: Changes in framework-04 draft Thread-Index: Ac0AmC5HBii3bpsOTAuOiBigz6DWIg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FC7DF1AC@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FC7DF1ACCRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Changes in framework-04 draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:37:32 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FC7DF1ACCRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Changes from 03 to 04: 1. Remove sentence from overview - "This constitutes a significant change ..." 2. Clarify a consumer can choose a subset of captures from a capture scene entry or a simultaneous set (in section "capture scene" and "consumer's choice..."). 3. Reword first paragraph of Media Capture Attributes section. 4. Clarify a stereo audio capture is different from two mono audio captures (description of audio channel format attribute). 5. Clarify what it means when coordinate information is not specified for area of capture, point of capture, area of scene. 6. Change the term "producer" to "provider" to be consistent (it was just in two places). 7. Change name of "purpose" attribute to "content" and refer to RFC4796 for values. 8. Clarify simultaneous sets are part of a provider advertisement, and apply across all capture scenes in the advertisement. 9. Remove sentence about lip-sync between all media captures in a capture scene. 10. Combine the concepts of "capture scene" and "capture set" into a single concept, using the term "capture scene" to replace the previous term "capture set", and eliminating the original separate capture scene concept. Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FC7DF1ACCRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

   Cha= nges from 03 to 04:

 

   1.   Remove sentence from over= view - "This constitutes a significant

        change ..."<= /p>

 

 &nb= sp; 2.   Clarify a consumer can choose a subset of captures from = a

      &n= bsp; capture scene entry or a simultaneous set (in section "capture

       = scene" and "consumer's choice...").

 

   3. = ;  Reword first paragraph of Media Capture Attributes section.

 

 = ;  4.   Clarify a stereo audio capture is different from two= mono audio

    &nbs= p;   captures (description of audio channel format attribute).

 

=    5.   Clarify what it means when coordinate informati= on is not

     =    specified for area of capture, point of capture, area of scene= .

 

   6.   Change the term "producer" to &qu= ot;provider" to be consistent (it

&= nbsp;       was just in two places).

 

 =   7.   Change name of "purpose" attribute to "= ;content" and refer to

  =       RFC4796 for values.

 

   8. = ;  Clarify simultaneous sets are part of a provider advertisement,

        = and apply across all capture scenes in the advertisement.

 

   9.=    Remove sentence about lip-sync between all media captures in a=

      &nb= sp; capture scene.

 

=

   10.  Combine the concepts of "c= apture scene" and "capture set" into a

        single concept, us= ing the term "capture scene" to replace the

        previous term &quo= t;capture set", and eliminating the original

        separate capture scene= concept.

 

Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FC7DF1ACCRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Mon Mar 12 14:38:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559DD21F893C for ; Mon, 12 Mar 2012 14:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyU61zS90iZQ for ; Mon, 12 Mar 2012 14:38:44 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2053A11E80E2 for ; Mon, 12 Mar 2012 14:38:44 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id kkXR1i00F1ZXKqc55lekjF; Mon, 12 Mar 2012 21:38:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id klek1i01807duvL3hlekDM; Mon, 12 Mar 2012 21:38:44 +0000 Message-ID: <4F5E6CE2.3080006@alum.mit.edu> Date: Mon, 12 Mar 2012 17:38:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Roni Even References: <20120312092050.9642.52271.idtracker@ietfa.amsl.com> <4F5E27FB.8080206@alum.mit.edu> <4f5e5b9b.c268b40a.5ce2.7d2f@mx.google.com> In-Reply-To: <4f5e5b9b.c268b40a.5ce2.7d2f@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:38:45 -0000 Comments inline. On 3/12/12 4:24 PM, Roni Even wrote: > Hi Paul, > I think that the major focus is point to point but see inline I think both need to be addressed. > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, March 12, 2012 6:45 PM >> To: clue@ietf.org >> Subject: Re: [clue] FW: New Version Notification for draft-even-clue- >> rtp-mapping-01.txt >> >> Roni, >> >> IIUC, you are proposing that the initial offer from an MCU would >> include the RTP streams required for all of the MCs it is advertising. >> Is that right? > > Roni: the initial offer should include RTP stream for the simultaneous Media > capture that the endpoint specified (for example there is no need to have a > separate m-line for a media capture coming from the same camera but offering > different view like zoom out and zoom in view). The m-line provide > information about the encoder which is a physical entity that in CLUE can be > used to provide different content that is defined by the CLUE protocol. If > it is an MCU it is an application decision what is the simultaneous set it > wants to distribute. But it must be consistent with the advertisement it is providing, right? And then it can get negotiated down from there if the other end selects less that was advertised? (E.g. if only a subset of the MCs in a Scene Entry are selected.) Or do you see a case where the initial offer doesn't cover the full advertisement? > My view is that it is what you also called a "virtual > room" that describes a common set for a conference that the MCU wants to > use, the MCU has also physical encoder constrains similar to an end point. > >> >> And each such stream would call for the maximum bandwidth required by >> any MC mapped to that stream? > > Roni: I assume that you are asking about MCU case. I don't think it matters. > If the conference is not > transcoding the MCU will offer to the participants the bw of the common mode > which is likely to be the minimum of all participants. BTW: this is not a > CLUE issue it applies to any MCU that does non transcoded video conferences I was asking about something else. Some scene entries may have more MCs than others. The MCs of one scene entry can share m-lines with the MCs of other scene entries. But for any one m-line the bw requirement for the offer must be the maximum of the bw required for each MC mapped to that m-line. >> That might be excessive if the other end ultimately selects fewer MCs. >> > Roni: the bw is per m-line (using b=TIAS:) and per the SDP session (using > b=AS: so if it uses less m-lines than less bw will be used as long as the > total is less than the SDP session bw parameter. But will the bw be initially allocated, risking call failure if it isn't available, even if less will actually be needed? What, if anything, are you assuming about bandwidth management? >> (Whether those are significant issues can be discussed later.) >> >> I also don't understand how the mapping of MCs to m-lines via RTP-id >> works once you consider that both ends are sending media. After the o/a >> exchange there must be a single set of m-lines. According to RF5888, >> the mid value in the affer MUST be the same as the mid value in the >> answer. >> That means the answerer can't insert its own mid values corresponding >> to its RTP-id values. Also, the m-lines in the answer are constrained >> by the m-lines in the offer. >> >> The only fix I see for this is to first exchange advertisements (and >> maybe selections too), then compute a set of m-lines that are >> sufficient to handle the bidirectional exchange of MCs, and then >> exchange an o/a for that. > > Roni: this is a good point and I will need to address it. Your proposal is > one option. I realized it was a problem, but didn't think much about solutions. My point was just to get discussion going on it. Actually I think this is a general problem for bundle, and probably needs to be discussed as part of the bundle proposal, on the mmusic list. > I think that even of offering a full set in the initial offer it is based on > what the offerer can send and receive using sendonly and recvonly attribute > if it has different encoding and decoding resources. You mean using different m-lines for each direction? Perhaps that is part of an answer, but if so it will take some working out. I think many/most vanilla sip endpoints won't work right if offered separate sendonly and recvonly m-lines. Also, while this could resolve the problem of binding m-lines to RTP-ids, it couldn't do so in one o/a cycle unless the initial offerer has received and advertisement from the answerer prior to the first offer. > If the offer for > example has three screens and cameras and the answer have one screen one > camera and decode more than one stream it can either use recvonly attribute > or after responding to the offer start a second offer/answer exchange to > addree the asymmetry. I'm not sure I follow the above. For the answerer to reuse any of the offered m-lines for sending media it will have to construct its advertisement to use the RTP-ids from those included in the offer. If those aren't suitable, then it will need to answer with recvonly for those m-lines that aren't being reused, and then initiate a new o/a that adds more m-lines. > CLUE also need two exchanges requiring advertisements > from both sides. I assume this is the limitation of RFC3264 and SDP yes > while if > using H.245 you specify receive and transmit capabilities (maybe use H.245 > for CLUE) Out of scope for CLUE. Thanks, Paul >> Maybe there is another way. In any case I think this needs to be >> addressed in the draft. >> >> Thanks, >> Paul (as individual) >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From marshall.eubanks@gmail.com Mon Mar 12 14:59:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3044021E80F5 for ; Mon, 12 Mar 2012 14:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.526 X-Spam-Level: X-Spam-Status: No, score=-103.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzaSg0CCcM+z for ; Mon, 12 Mar 2012 14:59:35 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 694F821E804D for ; Mon, 12 Mar 2012 14:59:35 -0700 (PDT) Received: by lbol12 with SMTP id l12so1457050lbo.31 for ; Mon, 12 Mar 2012 14:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=nris0m6uVsmduwWEmkuROkoz65Tux2CFANp4WJS8oGw=; b=jJMFvkwieDj7s9+1i+Z1BvQ+XKVnjKGweMBp9tZ6B4L0oU5fQnw6IGOK1cKVNQkqjy Jv4nt5SZ2l6yR6v6s1ih4yJ/r+QTay0GZEhzaGTtCG6spxY0wcvGoFKKCF2C48OGpW+N xuBMFZy3T9K1XA4/ym+Dfo8NEm4ABwcYJ85I/ZcJ7mN/UceFRDu3UPTmHKMO/Sdbuod9 vRYB6CqWW9U5w+L5jYzumA1Dcz1MwRf3rhj8/C9HIw5t8AZDtPtwPM8ISFWeS4hPtBk/ NW093xvgFlig7SgIkyW1jPfVusuLzcsu6/7pz8hyrSyZyU7JXKZku7kjNeQTGCFYOAiG /9LA== MIME-Version: 1.0 Received: by 10.152.132.130 with SMTP id ou2mr10518761lab.44.1331589574446; Mon, 12 Mar 2012 14:59:34 -0700 (PDT) Received: by 10.112.115.98 with HTTP; Mon, 12 Mar 2012 14:59:34 -0700 (PDT) In-Reply-To: <20120312212830.18279.48690.idtracker@ietfa.amsl.com> References: <20120312212830.18279.48690.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 17:59:34 -0400 Message-ID: From: Marshall Eubanks To: clue Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: New Version Notification for draft-wenger-clue-transport-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:59:37 -0000 For your reading pleasure. Naturally, I have already caught a typo. Regards Marshall ---------- Forwarded message ---------- From: Date: Mon, Mar 12, 2012 at 5:28 PM Subject: New Version Notification for draft-wenger-clue-transport-02.txt To: marshall.eubanks@gmail.com Cc: ron.even.tlv@gmail.com, stewe@stewe.org, gonzalo.camarillo@ericsson.com A new version of I-D, draft-wenger-clue-transport-02.txt has been successfully submitted by Marshall Eubanks and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-wenger-clue-transport Revision: =A0 =A0 =A0 =A002 Title: =A0 =A0 =A0 =A0 =A0 Transport Options for Clue Creation date: =A0 2012-03-12 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of pages: 13 Abstract: =A0 This memo describes the assumption and the proposed options for the =A0 coding and transport of CLUE messages as outlined in version 01 of =A0 the framework draft. The IETF Secretariat From pkyzivat@alum.mit.edu Mon Mar 12 15:14:44 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F2121F8A26 for ; Mon, 12 Mar 2012 15:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVEBH8uLwZua for ; Mon, 12 Mar 2012 15:14:44 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 165C421F8A27 for ; Mon, 12 Mar 2012 15:14:43 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta01.westchester.pa.mail.comcast.net with comcast id klot1i0081GhbT851mEk2v; Mon, 12 Mar 2012 22:14:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id kmEk1i00M07duvL3TmEku0; Mon, 12 Mar 2012 22:14:44 +0000 Message-ID: <4F5E7552.80201@alum.mit.edu> Date: Mon, 12 Mar 2012 18:14:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <20120312213500.22273.62133.idtracker@ietfa.amsl.com> In-Reply-To: <20120312213500.22273.62133.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:14:44 -0000 I'd like to propose a small addition to the definition of Capture Scene. The existing definition is: *Capture Scene: a structure representing the scene that is captured by a collection of capture devices. A capture scene includes attributes and one or more capture scene entries, with each entry including one or more media captures. I'd like to add a sentence to the end: "All the media captures in a capture scene share a common coordinate system." Thanks, Paul (as individual) From jonathan@vidyo.com Mon Mar 12 15:17:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395B221E8052 for ; Mon, 12 Mar 2012 15:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYzdInIVJ1Uw for ; Mon, 12 Mar 2012 15:17:15 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 85B0D21E80F1 for ; Mon, 12 Mar 2012 15:17:11 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C02FA553397 for ; Mon, 12 Mar 2012 18:17:10 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 52758553308 for ; Mon, 12 Mar 2012 18:17:10 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 12 Mar 2012 18:16:47 -0400 From: Jonathan Lennox To: "clue@ietf.org" Date: Mon, 12 Mar 2012 18:17:09 -0400 Thread-Topic: I-D Action: draft-lennox-clue-rtp-usage-03.txt Thread-Index: Ac0And4AK1P7DexEQk6fq5iGLAduVA== Message-ID: References: <20120312221118.7524.94723.idtracker@ietfa.amsl.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: [clue] Fwd: I-D Action: draft-lennox-clue-rtp-usage-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:17:17 -0000 Hello, all -- We've updated this draft following the discussion at the Andover Interim me= eting. The primary change is a section (Section 8) more formally listing the requi= rements that we think there are of a CLUE RTP architecture solution, which = we believe our proposal meets. Comments are welcome. Begin forwarded message: > From: "internet-drafts@ietf.org" > Date: March 12, 2012 6:11:18 PM EDT > To: "i-d-announce@ietf.org" > Subject: I-D Action: draft-lennox-clue-rtp-usage-03.txt > Reply-To: "internet-drafts@ietf.org" >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > Title : Real-Time Transport Protocol (RTP) Usage for Teleprese= nce Sessions > Author(s) : Jonathan Lennox > Paul Witty > Allyn Romanow > Filename : draft-lennox-clue-rtp-usage-03.txt > Pages : 18 > Date : 2012-03-12 >=20 > This document describes mechanisms and recommended practice for > transmitting the media streams of telepresence sessions using the > Real-Time Transport Protocol (RTP). >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-lennox-clue-rtp-usage-03.txt >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 -- Jonathan Lennox jonathan@vidyo.com From pkyzivat@alum.mit.edu Mon Mar 12 16:15:21 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B83F21F8AB3 for ; Mon, 12 Mar 2012 16:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYgcbjKx5kR5 for ; Mon, 12 Mar 2012 16:15:20 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 679D821F8AB8 for ; Mon, 12 Mar 2012 16:15:20 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta08.westchester.pa.mail.comcast.net with comcast id kn7C1i0030xGWP858nFLZt; Mon, 12 Mar 2012 23:15:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta12.westchester.pa.mail.comcast.net with comcast id knFL1i01L07duvL3YnFLqn; Mon, 12 Mar 2012 23:15:20 +0000 Message-ID: <4F5E8387.8090005@alum.mit.edu> Date: Mon, 12 Mar 2012 19:15:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <20120312212830.18279.48690.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Fwd: New Version Notification for draft-wenger-clue-transport-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:15:21 -0000 Section 3.1.2 Title is "Using an SDP MIME body to carry the CLUE information in an INVITE or UPDATE exchange". This should not mention SDP. (Its a non-SDP MIME body that is being proposed.) The concern about using UPDATE may be over stated. CLUE messages aren't negotiated - they're declarative - so there is no need to figure out anything before responding. There may be some desire to piggyback CLUE messages on the UPDATE responses to minimize traffic, but that can be optional, to be used if there is something ready to be sent. Section 5: Clue Discovery Another possibility not mentioned is to use a sip option tag for this. It allows signaling support using the Supported header, and required support using the Required header. (This can be useful if you don't want to call to succeed unless CLUE is supported. Also, sip caller capabilities feature tags could be used to indicate support and, using callerprefs mechanisms, to direct the initial preferentially to a CLUE supporting device. Note that something related to this (a proposed "immersive" feature tag) is under discussion on the dispatch list. These are not mutually exclusive. Thanks, Paul (as individual) From Mark.Duckworth@polycom.com Mon Mar 12 16:33:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0738C21E8205 for ; Mon, 12 Mar 2012 16:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd9hxzsexj9r for ; Mon, 12 Mar 2012 16:33:34 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id EB7F021E81FB for ; Mon, 12 Mar 2012 16:33:33 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 12 Mar 2012 16:33:32 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 12 Mar 2012 16:33:32 -0700 Thread-Topic: Capture scene definition Thread-Index: Ac0AqBWBU7noo7C2Qx2lEdo52rPLPg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FC7DF223@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: [clue] Capture scene definition X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:33:35 -0000 Hi Paul, Instead of expanding the definition, how about making it a bit more clear i= n the Spatial Relationships section? There is already this bullet item: o The coordinate system is Cartesian X, Y, Z with the origin at a spot of t= he provider's choosing. The provider must use the same origin for all coord= inates within the same capture scene. I propose change it to this: o The coordinate system is Cartesian X, Y, Z with the origin at a spot of t= he provider's choosing. The provider must use the same coordinate system wi= th same scale and origin for all coordinates within the same capture scene. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Monday, March 12, 2012 6:15 PM > To: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-04.txt >=20 > I'd like to propose a small addition to the definition of Capture Scene. > The existing definition is: >=20 > *Capture Scene: a structure representing the scene that is captured > by a collection of capture devices. A capture scene includes > attributes and one or more capture scene entries, with each entry > including one or more media captures. >=20 > I'd like to add a sentence to the end: >=20 > "All the media captures in a capture scene share a common coordinate > system." >=20 > Thanks, > Paul (as individual) >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Mar 12 17:38:28 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3739121E8073 for ; Mon, 12 Mar 2012 17:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DiGhD82BHA3 for ; Mon, 12 Mar 2012 17:38:27 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 218E021E8011 for ; Mon, 12 Mar 2012 17:38:26 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by QMTA11.westchester.pa.mail.comcast.net with comcast id kmUb1i0041vXlb85BoeTUD; Tue, 13 Mar 2012 00:38:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id koeT1i00R07duvL3doeTtP; Tue, 13 Mar 2012 00:38:27 +0000 Message-ID: <4F5E9701.9000801@alum.mit.edu> Date: Mon, 12 Mar 2012 20:38:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Duckworth, Mark" References: <44C6B6B2D0CF424AA90B6055548D7A6102FC7DF223@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FC7DF223@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Capture scene definition X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:38:28 -0000 OK - this WFM. Thanks, Paul On 3/12/12 7:33 PM, Duckworth, Mark wrote: > Hi Paul, > > Instead of expanding the definition, how about making it a bit more clear in the Spatial Relationships section? There is already this bullet item: > > o The coordinate system is Cartesian X, Y, Z with the origin at a spot of the provider's choosing. The provider must use the same origin for all coordinates within the same capture scene. > > I propose change it to this: > > o The coordinate system is Cartesian X, Y, Z with the origin at a spot of the provider's choosing. The provider must use the same coordinate system with same scale and origin for all coordinates within the same capture scene. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Monday, March 12, 2012 6:15 PM >> To: clue@ietf.org >> Subject: Re: [clue] I-D Action: draft-ietf-clue-framework-04.txt >> >> I'd like to propose a small addition to the definition of Capture Scene. >> The existing definition is: >> >> *Capture Scene: a structure representing the scene that is captured >> by a collection of capture devices. A capture scene includes >> attributes and one or more capture scene entries, with each entry >> including one or more media captures. >> >> I'd like to add a sentence to the end: >> >> "All the media captures in a capture scene share a common coordinate >> system." >> >> Thanks, >> Paul (as individual) >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Mar 12 18:18:30 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A879321F885F for ; Mon, 12 Mar 2012 18:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.506 X-Spam-Level: X-Spam-Status: No, score=-103.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UshoC64iX0nm for ; Mon, 12 Mar 2012 18:18:30 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2321F881B for ; Mon, 12 Mar 2012 18:18:29 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so16739vcb.31 for ; Mon, 12 Mar 2012 18:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VPwq/e4KKmQQE0422Pd19B7sBHy71paCuvyTwx3jFXs=; b=lpuiM0ETEgOhgjsf0NhhnxoGGULE+n0U5LHqbWb3rFuqwqYvxWaR98cupvoLbalY4K X7AsU6Rjtx8Z3hnBGy8QPJ9RZN19bVCtdimyWkTJUzjz5e1j+1k1d9WmnQtg9u5a54+D UXl97vxo/+4RTkZ14LVepOXfqDLDDlHO4u1Xiu7ANy66SqCZ1yeuW7D+dSRWMgtaR28S jKUmHFm0XdWcPngkRTVTfJ2Irb1RIO2gQCUVAsYdndKxb4e6Bla3keHrMG6rhao14fN+ d7x05HGWojJQAaepY5VL184oMkHcH+Aa8tqsnQh2bJHiZKhL++66S0oj8pI1AMyPJ54m 9oPA== MIME-Version: 1.0 Received: by 10.52.17.82 with SMTP id m18mr15825928vdd.89.1331601509440; Mon, 12 Mar 2012 18:18:29 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Mon, 12 Mar 2012 18:18:29 -0700 (PDT) Date: Mon, 12 Mar 2012 20:18:29 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec50405d6f3dc2404bb15a2e9 Subject: [clue] No design team call tomorrow - Tuesday, March 13th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 01:18:30 -0000 --bcaec50405d6f3dc2404bb15a2e9 Content-Type: text/plain; charset=ISO-8859-1 Since everyone has been very busy updating docs, I'm not sure that there is value in a call tomorrow. We could have one on the 20th if folks think that would be useful. Please let the chairs know if you think it would be worthwhile to discuss a particular topic before the interim. Thanks, Mary. --bcaec50405d6f3dc2404bb15a2e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Since everyone has been very busy updating docs, I'm not sure that ther= e is value in a call tomorrow. =A0 We could have one on the 20th if folks t= hink that would be useful. =A0Please let the chairs know if you think it wo= uld be worthwhile to discuss a particular topic before the interim.

Thanks,
Mary.=A0
--bcaec50405d6f3dc2404bb15a2e9-- From allyn@cisco.com Wed Mar 14 16:34:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9D011E808A for ; Wed, 14 Mar 2012 16:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.227 X-Spam-Level: X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVCta5iXRj3J for ; Wed, 14 Mar 2012 16:34:28 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 455B511E8075 for ; Wed, 14 Mar 2012 16:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1898; q=dns/txt; s=iport; t=1331768068; x=1332977668; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=A9XSUUe6Hm36sImBs1HJrZqxKQIwi5FcOV8/U9/k7gk=; b=D0PaUTi7KnFRXbkZfS4bQIkCOT/eBFVUwbBJYALuO3vMS3IbIz/SwqAh WF7rTBgQJrZnPOmyUiBA0XpvoyvimJVmR71m7hdQkO74vDo/x5Vqf1nTL s59EWbfl1D3TU47prr2aLZKLjJRilbekdLGpmS8R/4P3Kk6TGbRhzVxev M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABsqYU+rRDoJ/2dsb2JhbABDhTqvdn2BB4IJAQEBBBIBEA0EQw4GAQgRBAEBAwIGBhcBAgIDAUQHAQEFBAEEEwgah2cBmXiBJ40EkiaBL4wuggwzYwSIV4kckiOBaIMG X-IronPort-AV: E=Sophos;i="4.73,587,1325462400"; d="scan'208";a="33601530" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2012 23:34:28 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2ENYRLo016312 for ; Wed, 14 Mar 2012 23:34:28 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 16:34:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Wed, 14 Mar 2012 16:34:25 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0702B233@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-romanow-clue-sdp-usage-01.txt Thread-Index: Ac0Ao5knKZmYG2ZAQnuH6Lzl8d0AywAzGpNA From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 14 Mar 2012 23:34:27.0923 (UTC) FILETIME=[FF5C9A30:01CD023A] Subject: [clue] FW: New Version Notification for draft-romanow-clue-sdp-usage-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 23:34:29 -0000 Rm9sa3MsDQpXZSBzdWJtaXR0ZWQgdGhpcyBkcmFmdCB3aGljaCBpbnZlc3RpZ2F0ZXMgaG93IHRv IGNhcnJ5IHByb3ZpZGVyIGVuY29kaW5nIGFuZCBlbmNvZGluZyBncm91cCBhZHZlcnRpc2VtZW50 cyBpbiBTRFAuIChvcHRpb24gMiBpbiBQYXVsJ3Mgbm90ZSkNCg0KSXQgd2FzIHN1Z2dlc3RlZCB0 aGF0IGl0J3MgaW1wb3J0YW50IHRvIGhhdmUgdGhpcyBpbmZvcm1hdGlvbiBhdmFpbGFibGUgaW4g DQpTRFAgLS0gaGVuY2UgdGhlIGRyYWZ0LiBJdCB3b3VsZCBiZSBncmVhdCB0byBoZWFyIGZyb20g a25vd2xlZGdlYWJsZSBwZW9wbGUgaWYgdGhleSB0aGluayB0aGVzZSBDTFVFIHBhcmFtZXRlcnMg YXJlIHZhbHVhYmxlIGluIFNEUCBvciBub3QgLSBJJ3ZlIGhlYXJkIHNwZWN1bGF0aW9uIG9uIGJv dGggc2lkZXMuDQoNCg0KQ2hlZXJzLA0KQWxseW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1hcmNoIDEyLCAyMDEyIDM6NTggUE0NClRvOiBB bGx5biBSb21hbm93IChhbGx5bikNCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKTsg QXJ1biBLcmlzaG5hIChhcnVrcmlzaCkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtcm9tYW5vdy1jbHVlLXNkcC11c2FnZS0wMS50eHQNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LXJvbWFub3ctY2x1ZS1zZHAtdXNhZ2UtMDEudHh0IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWxseW4gUm9tYW5vdyBhbmQgcG9zdGVkIHRvIHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtcm9tYW5vdy1jbHVlLXNkcC11c2Fn ZQ0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgSW52ZXN0aWdhdGlvbiBvZiBTZXNzaW9uIERlc2Ny aXB0aW9uIFByb3RvY29sIChTRFApIFVzYWdlIGZvciBDb250cm9MbGluZyBtVWx0aXBsZSBzdHJl YW1zIGZvciB0RWxlcHJlc2VuY2UgKENMVUUpDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wMy0xMg0K V0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIzDQoNCkFi c3RyYWN0Og0KICAgVGhpcyBkcmFmdCBpbnZlc3RpZ2F0ZXMgaG93IFNEUCBvZmZlci9hbnN3ZXIg Y2FuIGJlIHVzZWQgdG8NCiAgIGNvbW11bmljYXRlIENMVUUgZW5jb2RpbmcgYW5kIGVuY29kaW5n IGdyb3VwIHBhcmFtZXRlcnMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0K From keith.drage@alcatel-lucent.com Thu Mar 15 04:09:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73A721F861D for ; Thu, 15 Mar 2012 04:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.552 X-Spam-Level: X-Spam-Status: No, score=-109.552 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+4rFoaXufLO for ; Thu, 15 Mar 2012 04:09:58 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 128F621F8619 for ; Thu, 15 Mar 2012 04:09:57 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2FAxku8028581 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 15 Mar 2012 12:09:55 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 15 Mar 2012 12:09:36 +0100 From: "DRAGE, Keith (Keith)" To: "clue@ietf.org" Date: Thu, 15 Mar 2012 12:09:33 +0100 Thread-Topic: Do we have an agenda yet???? Thread-Index: Ac0CnBmjBi5fv8jKTBOKsGqY3KWu9g== Message-ID: 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 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [clue] Do we have an agenda yet???? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:09:58 -0000 As title - deadline was last night for posting. Keith From mary.ietf.barnes@gmail.com Thu Mar 15 07:04:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06C621F8624 for ; Thu, 15 Mar 2012 07:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6qcWtN1yglB for ; Thu, 15 Mar 2012 07:04:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6D21F861E for ; Thu, 15 Mar 2012 07:04:37 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3910361vcb.31 for ; Thu, 15 Mar 2012 07:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rsjQBTDKWwvro8iPz9rKzSVPaqqCfeAFLKeQTiYuRns=; b=ucx5GeW31/U6Dwus06myuCCud3VatAOZYot8yzStVhs5SLQpWQoxBShY22RGdti+GU DbioL8tZEgMF+qycvvonOBKXZPgj0yeL5Z6qhD6eBfCQlmxqYlKLurVSRfUrXA7GYROB oz+acETdU7TcrwtPnN41qmlQoAi6IlluW4jqzFlvhOKFKsnBNSGchi7BLlP5GbbxzCp5 LULUaXndo66XaQo8QEcqfBGkOQYTgzLM2CbauFmhICXr8kZsJBbXrH362AJ4JvGSdk6D 8FIBoZOriuTvcwoB87vCKZtxtsbcLDHv49QeY5rU6XUVO3b/aGwtoUjwmhBU9FTAntjg jXlQ== MIME-Version: 1.0 Received: by 10.52.88.103 with SMTP id bf7mr4719612vdb.72.1331820277374; Thu, 15 Mar 2012 07:04:37 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Thu, 15 Mar 2012 07:04:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 09:04:37 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/mixed; boundary=20cf307f3c04899de604bb489212 Cc: "clue@ietf.org" Subject: Re: [clue] Do we have an agenda yet???? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:04:38 -0000 --20cf307f3c04899de604bb489212 Content-Type: multipart/alternative; boundary=20cf307f3c04899ddf04bb489210 --20cf307f3c04899ddf04bb489210 Content-Type: text/plain; charset=ISO-8859-1 I have problems with accessing meeting materials manager as somehow I still have two ids in the system (which the secretariat is aware of and will need to fix). I have forwarded to my co-chair to upload and I am attaching. Mary. On Thu, Mar 15, 2012 at 6:09 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > As title - deadline was last night for posting. > > Keith > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --20cf307f3c04899ddf04bb489210 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have problems with accessing meeting materials manager as somehow I still= have two ids in the system (which the secretariat is aware of and will nee= d to fix). =A0I have forwarded to my co-chair to upload and I am attaching.= =A0

Mary.

On Thu, Mar 15, 201= 2 at 6:09 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
As title - deadline was last night for posti= ng.

Keith
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--20cf307f3c04899ddf04bb489210-- --20cf307f3c04899de604bb489212 Content-Type: text/html; charset=US-ASCII; name="clue-agenda-v1.html" Content-Disposition: attachment; filename="clue-agenda-v1.html" Content-Transfer-Encoding: base64 X-Attachment-Id: f_gztvecjr0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4KPGh0bWw+PGhlYWQ+CjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPgo8bWV0YSBodHRwLWVxdWl2PSJjb250 ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xIj48dGl0bGU+ Q2x1ZSBBZ2VuZGE8L3RpdGxlPjwvaGVhZD4KPGJvZHk+CjxoMT5DTFVFIFdHIC0gSUVURiA4Mzwv aDE+CjxwcmU+Q0xVRSBXRyBDaGFpcnM6IDxhIGhyZWY9Im1haWx0bzptYXJ5LmJhcm5lc0Bwb2x5 Y29tLmNvbSI+TWFyeSBCYXJuZXM8L2E+IGFuZCA8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1 bS5taXQuZWR1Ij48c3BhbiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5QYXVs IEt5eml2YXQ8L3NwYW4+PC9hPiA8L3ByZT4KCjxoMz5EYXRlL1RpbWUgKFdHIHNlc3Npb24gMSk6 IFR1ZXNkYXksIE1hci4gMjd0aCwgMDkwMC0xMTMwCiZuYnNwO0xlbmd0aDoKMi41IGhvdXJzJm5i c3A7IExvY2F0aW9uOiAyNTJCPC9oMz48cHJlPjxpPkNyZWF0ZWQgb24gTWFyY2ggMTQsIDIwMTI8 YnI+PC9pPjwvcHJlPgo8aHIgc3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDJweDsiPgoKPHRh YmxlIHN0eWxlPSJ0ZXh0LWFsaWduOiBsZWZ0OyB3aWR0aDogNzgzcHg7IGhlaWdodDogMjE3cHg7 IiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiI+PGNhcHRpb24+IDxi cj4KPC9jYXB0aW9uPjx0Ym9keT4KPC90Ym9keT4gPHRib2R5Pgo8dHI+Cjx0ZCBzdHlsZT0idmVy dGljYWwtYWxpZ246IHRvcDsgZm9udC13ZWlnaHQ6IGJvbGQ7IiBoZWlnaHQ9IjE5IiB3aWR0aD0i MTEyIj5UaW1lIDwvdGQ+Cjx0ZCBzdHlsZT0idmVydGljYWwtYWxpZ246IHRvcDsgZm9udC13ZWln aHQ6IGJvbGQ7IiBoZWlnaHQ9IjE5IiB3aWR0aD0iNDkiPkxlbmd0aDwvdGQ+Cjx0ZCBzdHlsZT0i dmVydGljYWwtYWxpZ246IHRvcDsgZm9udC13ZWlnaHQ6IGJvbGQ7IiBoZWlnaHQ9IjE5IiB3aWR0 aD0iMTQyIj5QcmVzZW50ZXI8L3RkPgoKPHRkPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDogYm9s ZDsiPlRvcGljPC9zcGFuPjwvdGQ+PHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250 LXdlaWdodDogYm9sZDsiIGhlaWdodD0iMTkiIHdpZHRoPSI0NzYiPkRvY3VtZW50czwvdGQ+Cjwv dHI+Cjx0cj4KPHRkIGhlaWdodD0iMTkiIHdpZHRoPSIxMTIiPjA5OjAwLTA5OjEwPGJyPgo8L3Rk Pgo8dGQgaGVpZ2h0PSIxOSIgd2lkdGg9IjQ5Ij4KPHAgc3R5bGU9InRleHQtYWxpZ246IGNlbnRl cjsiPjEwPC9wPgo8L3RkPgo8dGQgaGVpZ2h0PSIxOSIgd2lkdGg9IjE0MiI+Q2hhaXJzPC90ZD4K Cjx0ZD5BZ2VuZGEgYW5kIFN0YXR1czwvdGQ+PHRkIGhlaWdodD0iMTkiIHdpZHRoPSI0NzYiPiAm bmJzcDs8L3RkPgo8L3RyPgoKCgo8dHI+PHRkPjA5OjEwLTEwOjEwPC90ZD48dGQgc3R5bGU9InRl eHQtYWxpZ246IGNlbnRlcjsiPjYwPC90ZD48dGQ+PGEgaHJlZj0ibWFpbHRvOm1hcmsuZHVja3dv cnRoQHBvbHljb20uY29tIj5NYXJrCkR1Y2t3b3J0aDwvYT48YSBocmVmPSJtYWlsdG86YXBlcHBl cmVAY2lzY28uY29tIj48YnI+PC9hPjxhIGhyZWY9Im1haWx0bzpiYmFsZGlub0BjaXNjby5jb20i PjwvYT48L3RkPjx0ZD5GcmFtZXdvcms8L3RkPjx0ZD48YSBocmVmPSJodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2x1ZS1mcmFtZXdvcmsvIiB0YXJnZXQ9Il9ibGFu ayI+ZHJhZnQtaWV0Zi1jbHVlLWZyYW1ld29yazwvYT48YnI+CjwvdGQ+PC90cj48dHI+PHRkPjEw OjEwLTEwOjQwPC90ZD48dGQgc3R5bGU9InRleHQtYWxpZ246IGNlbnRlcjsiPjMwPC90ZD48dGQ+ PGEgaHJlZj0ibWFpbHRvOnN0ZXdlQHN0ZXdlLm9yZyI+U3RlcGhhbiBXZW5nZXI8L2E+PC90ZD48 dGQ+VHJhbnNwb3J0IE9wdGlvbnMgPC90ZD48dGQ+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC13ZW5nZXItY2x1ZS10cmFuc3BvcnQvIj5kcmFmdC13ZW5nZXIt Y2x1ZS10cmFuc3BvcnQ8L2E+PC90ZD48L3RyPjx0cj4KPHRkPjEwOjQwLTExOjEwPC90ZD4KPHRk IHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij4zMDwvdGQ+Cjx0ZD48YSBocmVmPSJtYWlsdG86 YWxseW5AY2lzY28uY29tIj5BbGx5biBSb21hbm93PC9hPjxicj4KPC90ZD48dGQ+U0RQIHVzYWdl IGZvciBDTFVFPC90ZD48dGQ+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1yb21hbm93LWNsdWUtc2RwLXVzYWdlLyI+ZHJhZnQtcm9tYW5vdy1jbHVlLXNkcC11 c2FnZTwvYT48L3RkPgo8L3RyPjx0cj48dGQ+MTE6MTAtMTE6MzA8L3RkPjx0ZCBzdHlsZT0idGV4 dC1hbGlnbjogY2VudGVyOyI+MjA8L3RkPjx0ZD48YSBocmVmPSJtYWlsdG86c3RlcGhhbmUuY2F6 ZWF1eEBvcmFuZ2UuY29tIj5TdGVwaGFuZSBDYXplYXV4PC9hPjxicj4KPC90ZD48dGQ+UmVxdWly ZW1lbnRzIGZvciBDTFVFIFNpZ25hbGluZzwvdGQ+PHRkPjxhIHRhcmdldD0iX2JsYW5rIiBocmVm PSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNhemVhdXgtY2x1ZS1zaXAt c2lnbmFsaW5nLyI+ZHJhZnQtY2F6ZWF1eC1jbHVlLXNpcC1zaWduYWxpbmc8L2E+PC90ZD48L3Ry PjwvdGJvZHk+PC90YWJsZT48YnI+PGgzPkRhdGUvVGltZSAoV0cgc2Vzc2lvbiAyKTogVGh1cnNk YXksIE1hci4gMjl0aCwgMTc0MC0xOTQwCiZuYnNwO0xlbmd0aDoKMi4wIGhvdXJzJm5ic3A7IExv Y2F0aW9uOiBNYWlsbG90PC9oMz48cHJlPjxpPkNyZWF0ZWQgb24gTWFyY2ggMTQsIDIwMTI8L2k+ PC9wcmU+Cjx0YWJsZSBzdHlsZT0idGV4dC1hbGlnbjogbGVmdDsgd2lkdGg6IDY5N3B4OyBoZWln aHQ6IDIxMnB4OyIgYm9yZGVyPSIxIiBjZWxscGFkZGluZz0iMiIgY2VsbHNwYWNpbmc9IjIiPgo8 dGJvZHk+Cjx0cj4KPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXdlaWdodDog Ym9sZDsiIGhlaWdodD0iMTkiIHdpZHRoPSIxMTIiPlRpbWUgPC90ZD4KPHRkIHN0eWxlPSJ2ZXJ0 aWNhbC1hbGlnbjogdG9wOyBmb250LXdlaWdodDogYm9sZDsiIGhlaWdodD0iMTkiIHdpZHRoPSI0 OSI+TGVuZ3RoPC90ZD4KPHRkIHN0eWxlPSJ2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXdlaWdo dDogYm9sZDsiIGhlaWdodD0iMTkiIHdpZHRoPSIxNDIiPkxlYWRlcihzKSA8L3RkPgo8dGQgc3R5 bGU9InZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtd2VpZ2h0OiBib2xkOyIgaGVpZ2h0PSIxOSIg d2lkdGg9IjE4MSI+VG9waWM8L3RkPgo8dGQgc3R5bGU9InZlcnRpY2FsLWFsaWduOiB0b3A7IGZv bnQtd2VpZ2h0OiBib2xkOyIgaGVpZ2h0PSIxOSIgd2lkdGg9IjQ3NiI+RHJhZnQocyk8L3RkPgo8 L3RyPgo8dHI+Cjx0ZCBoZWlnaHQ9IjE5IiB3aWR0aD0iMTEyIj4xNzo0MC0xNzo1MDxicj4KPC90 ZD4KPHRkIGhlaWdodD0iMTkiIHdpZHRoPSI0OSI+CjxwIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50 ZXI7Ij4xMDwvcD4KPC90ZD4KPHRkIGhlaWdodD0iMTkiIHdpZHRoPSIxNDIiPkNoYWlycyZuYnNw OzwvdGQ+Cjx0ZCBoZWlnaHQ9IjE5IiB3aWR0aD0iMTgxIj5BZ2VuZGEgYmFzaDwvdGQ+Cjx0ZD48 YnI+PC90ZD4KPC90cj4KPHRyPgo8dGQ+MTc6NTAtMTg6MjA8L3RkPgo8dGQgc3R5bGU9InRleHQt YWxpZ246IGNlbnRlcjsiPjMwPC90ZD4KPHRkPjxhIGhyZWY9Im1haWx0bzpqb25hdGhhbkB2aWR5 by5jb20iPkpvbmF0aGFuIExlbm5veDwvYT48YnI+CjwvdGQ+PHRkPlJUUCBVc2FnZTwvdGQ+PHRk PjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGVubm94LWNs dWUtcnRwLXVzYWdlLyI+ZHJhZnQtbGVubm94LWNsdWUtcnRwLXVzYWdlPC9hPjwvdGQ+CgoKPC90 cj48dHI+PHRkPjE4OjIwLTE4OjUwPC90ZD48dGQgc3R5bGU9InRleHQtYWxpZ246IGNlbnRlcjsi PjMwPC90ZD48dGQ+PGEgaHJlZj0ibWFpbHRvOmJvLmJ1cm1hbm5AZXJpY3Nzb24uY29tIj5Sb25p IEV2ZW48L2E+PC90ZD48dGQ+UlRQIE1hcHBpbmcgPGJyPjwvdGQ+PHRkPjxhIGhyZWY9Imh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZXZlbi1jbHVlLXJ0cC1tYXBwaW5nLyI+ ZHJhZnQtZXZlbi1jbHVlLXJ0cC1tYXBwaW5nPC9hPjxicj48L3RkPjwvdHI+PHRyPjx0ZD4xODo1 MC0xOToxMDwvdGQ+PHRkIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij4yMDwvdGQ+PHRkPjxh IGhyZWY9Im1haWx0bzpiby5idXJtYW5uQGVyaWNzc29uLmNvbSI+Qm8gQnVybWFubjwvYT48L3Rk Pjx0ZD5NdWx0aS1zdHJlYW0mbmJzcDs8YnI+PC90ZD48dGQ+PGEgaHJlZj0iZHJhZnQtd2VzdGVy bHVuZC1jbHVlLW11bHRpc3RyZWFtLWNvbmZlcmVuY2UiIHRhcmdldD0iX2JsYW5rIj5kcmFmdC13 ZXN0ZXJsdW5kLWNsdWUtbXVsdGlzdHJlYW0tY29uZmVyZW5jZTwvYT48YnI+PC90ZD48L3RyPjx0 cj48dGQ+MTk6MTAtMTk6MzA8L3RkPjx0ZCBzdHlsZT0idGV4dC1hbGlnbjogY2VudGVyOyI+MjA8 L3RkPjx0ZD5DaGFpcnM8L3RkPjx0ZD5PcGVuIERpc2N1c3Npb248L3RkPjx0ZD48L3RkPjwvdHI+ PHRyPjx0ZD4xOToxMC0xOTo0MDwvdGQ+PHRkIHN0eWxlPSJ0ZXh0LWFsaWduOiBjZW50ZXI7Ij4z MDwvdGQ+PHRkPkNoYWlyczwvdGQ+PHRkPjxicj5XcmFwLXVwL1dheSBGb3J3YXJkPC90ZD48dGQ+ PGJyPjwvdGQ+PC90cj4KPC90Ym9keT4KPC90YWJsZT4KPGJyPgo8c3BhbiBzdHlsZT0iZm9udC1z dHlsZTogaXRhbGljOyI+PGJyPjwvc3Bhbj48YnI+PHA+CjwvcD4KPGhyIHN0eWxlPSJ3aWR0aDog MTAwJTsgaGVpZ2h0OiAycHg7Ij4mbmJzcDsmbmJzcDs8YnI+Cjxicj4KPC9ib2R5PjwvaHRtbD4= --20cf307f3c04899de604bb489212-- From pkyzivat@alum.mit.edu Thu Mar 15 09:13:18 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301DB21F87A4 for ; Thu, 15 Mar 2012 09:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DikU7JFXwrP for ; Thu, 15 Mar 2012 09:13:16 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 83A3F21F87A2 for ; Thu, 15 Mar 2012 09:13:16 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id lqso1i0091vXlb851sDHPm; Thu, 15 Mar 2012 16:13:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id lsDG1i00607duvL3dsDG3q; Thu, 15 Mar 2012 16:13:17 +0000 Message-ID: <4F62151B.6040909@alum.mit.edu> Date: Thu, 15 Mar 2012 12:13:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Do we have an agenda yet???? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:13:18 -0000 I just uploaded them. Feel free to comment. Thanks, Paul On 3/15/12 10:04 AM, Mary Barnes wrote: > I have problems with accessing meeting materials manager as somehow I > still have two ids in the system (which the secretariat is aware of and > will need to fix). I have forwarded to my co-chair to upload and I am > attaching. > > Mary. > > On Thu, Mar 15, 2012 at 6:09 AM, DRAGE, Keith (Keith) > > > wrote: > > As title - deadline was last night for posting. > > Keith > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From espeberg@cisco.com Fri Mar 16 08:46:03 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35721F866D for ; Fri, 16 Mar 2012 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.934 X-Spam-Level: X-Spam-Status: No, score=-9.934 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-rHWodL3wIx for ; Fri, 16 Mar 2012 08:46:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C3F4421F866C for ; Fri, 16 Mar 2012 08:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=3735; q=dns/txt; s=iport; t=1331912756; x=1333122356; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=17ah4xW/1+dxjkQv8BWFQlWd3C3wyp1chqJ2hKvmbl8=; b=Jr38ce5P4OshCSupG7TwMIMuELwygnzOgGdUt1xLhWGuGmtF00/dwbpk jm270DQ3n4dKc1A8NytksLrwRxser4uDvtQa2eLXOnIkRoqYl+O2+S5Oo 4v61pSujrmB0HPHkO1mM+dF+J05RGCHM1qr+/3076tm9DzLh3YT/msQHS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO9eY0+Q/khN/2dsb2JhbABCDrYpgQeCCQEBAQMBAQEBDwEdCi4GEAcEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAESCAEZh2MFC5punyCKRoVUYwSkJYFogi84gVs X-IronPort-AV: E=Sophos;i="4.73,598,1325462400"; d="scan'208";a="132552435" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 16 Mar 2012 15:45:54 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2GFjs84020232; Fri, 16 Mar 2012 15:45:54 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 16:45:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 16:45:53 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E0109C145@XMB-AMS-214.cisco.com> In-Reply-To: <4F5A8898.3050504@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] New ticket (#8) for how consumer differentiates between multiple capture scenes Thread-Index: Acz+Rq4Z/kMps0b9S/6sKg6CVoZHvgFRIfsQ References: <4F5A8898.3050504@alum.mit.edu> From: "Espen Berger (espeberg)" To: "Paul Kyzivat" , "CLUE" X-OriginalArrivalTime: 16 Mar 2012 15:45:54.0659 (UTC) FILETIME=[DF607330:01CD038B] Subject: Re: [clue] New ticket (#8) for how consumer differentiates between multiple capture scenes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:46:03 -0000 A textual description, e.g. like srcname, to describe a capture or capture scene is valuable for use cases where an endpoint want to advertise multiple camera source that are only identified by name. In a medical use case the srcnames could be "knife cam", "doctor", and so on. If we want to support MCU case where the MCU forward all advertisements to everyone, a endpoint-source would be useful to differentiate between multiple source endpoints that could announce capture sets with the same srcname.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 9. mars 2012 23:48 To: CLUE Subject: Re: [clue] New ticket (#8) for how consumer differentiates between multiple capture scenes Thanks Mary for standing back and pointing out I had created another issue. Since I seem to have been the guilty party in bringing this up, I can kick off the discussion. On 3/9/12 4:59 PM, Mary Barnes wrote: > One topic that seemed to surface in the discussion of ticket #7 is=20 > around how the consumer differentiates between multiple capture scenes: > http://www.ietf.org/mail-archive/web/clue/current/msg01165.html > > A couple things might help in determining a way forward for this one are: > 1) Is there a use case that requires this functionality and which is it? > ISTM it *might* be I was thinking of an MCU that decides it wants to "pass through" Capture Scenes it receives. Thus the advertisements it makes could include a separate Capture Scene or Scenes from each endpoint participating in the conference. (Of course it could include just an interesting subset of these, or also include some other Scenes that it synthesizes, but lets stick with this for discussion.) So if rooms X,Y,Z are connected to the MCU, each might have one scene containing captures for all of its cameras, and another scene containing a presentation. So the advertisement from the MCU to Z would contain four scenes, two from X and two Y. In a typical case the captures from all the cameras might have purpose=3Dmain, while presentation captures have purpose=3Dpresentation. = But there is no obvious way to tell which captures come from X and which come from Y. This could be handled either by attributes on the individual captures, or by attributes on the capture scenes. I don't see how this would help with algorithmically sorting things out, but at least it could provide some data for a UI display to pick what to display. I don't see anything currently defined in the framework that meets this need. A simple text description of each capture, or of the scene, would probably be sufficient. > 2) If we agree the use case, are the requirements in the requirements=20 > document sufficient? This may be covered by REQMT-1 which requires support for describing the spacial arrangement of sources. What we have specified so far describes the spacial arrangement of sources within a single scene. But it isn't capable of describing the spacial arrangement of sources within multiple scenes from different sources. (Though I'm talking about a textual description, which is something like a civil address, rather than a coordinate.) This also might, in part, be covered by REQMT-15 about presentations, because if there is more than one presentation there is currently no way to indicate the meaning of each, even if they are in a single scene. We can discuss if those are sufficient, or if there is some different requirement here. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From magnus.westerlund@ericsson.com Fri Mar 16 08:48:41 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5899321F866D for ; Fri, 16 Mar 2012 08:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.377 X-Spam-Level: X-Spam-Status: No, score=-110.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMjKPp5BZnXQ for ; Fri, 16 Mar 2012 08:48:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB6A21F866C for ; Fri, 16 Mar 2012 08:48:39 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-6d-4f6360d72446 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CF.C7.27041.7D0636F4; Fri, 16 Mar 2012 16:48:39 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Mar 2012 16:48:38 +0100 Message-ID: <4F6360D6.9030604@ericsson.com> Date: Fri, 16 Mar 2012 16:48:38 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: CLUE References: <4F635D10.3040607@ericsson.com> In-Reply-To: <4F635D10.3040607@ericsson.com> X-Enigmail-Version: 1.4 Content-Type: multipart/mixed; boundary="------------070609050803020802050108" X-Brightmail-Tracker: AAAAAA== Subject: [clue] Fwd: [dispatch] Media Stream Related Signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: DISPATCH list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:48:41 -0000 --------------070609050803020802050108 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit CLUE WG, As the functionality proposed concerns multi-party conferences and are especially useful in multi-source end-points like Telepresence end-points I expect that some are interested in this WG. The discussion will happen in Paris in the Dispatch WG session, currently scheduled for Tuesday (27th of March) at 1300-1500. If you already now have input in the discussion please send email to the Dispatch WG mailing list. Cheers Magnus --------------070609050803020802050108 Content-Type: message/rfc822; name="[dispatch] Media Stream Related Signaling.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="[dispatch] Media Stream Related Signaling.eml" X-Mozilla-Keys: Received: from sesbmg10.ericsson.net (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.89) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 16 Mar 2012 16:32:40 +0100 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by sesbmg10.ericsson.net (Symantec Mail Security) with SMTP id A3.ED.03823.81D536F4; Fri, 16 Mar 2012 16:32:40 +0100 (CET) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86EB21F8711; Fri, 16 Mar 2012 08:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4405C21F8709 for ; Fri, 16 Mar 2012 08:32:35 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KcNVfIl1OhU for ; Fri, 16 Mar 2012 08:32:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7C621F86D5 for ; Fri, 16 Mar 2012 08:32:34 -0700 (PDT) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C4.11.17856.11D536F4; Fri, 16 Mar 2012 16:32:33 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Fri, 16 Mar 2012 16:32:32 +0100 From: Magnus Westerlund To: DISPATCH list Sender: "dispatch-bounces@ietf.org" Date: Fri, 16 Mar 2012 16:32:32 +0100 Subject: [dispatch] Media Stream Related Signaling Thread-Topic: [dispatch] Media Stream Related Signaling Thread-Index: Ac0DigZOdrBIp9HVQ6m5uCDvQ8b40Q== Message-ID: <4F635D10.3040607@ericsson.com> References: <4F635AF9.9020605@ericsson.com> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <4F635AF9.9020605@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: esessmw0197.eemea.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-auditid: c1b4fb3c-b7f126d000000eef-25-4f635d171dd7 x-brightmail-tracker: AAAAAA== dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1331911958; bh=InyQ1CufGR9qkZDp9pnRK+DMwxIXvg5eclqpB6XDScQ=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=h5Q1xvKpRAVpgVLge5pdbt5xmqCZRVoNRo2Xb0EiC5eP9mkkMxWhR3CtMzttMTGvK sh5FxZy/w+QEJAKSpfpH2uz8GzKe61DEGI3cdXyCOIcA1j0iN9V1qUVXrMscJAmk85 fBjrbqCZd0ypCAlFdW11JrpvEg2dQiABoc+rxvfk= user-agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 errors-to: dispatch-bounces@ietf.org x-virus-scanned: amavisd-new at amsl.com x-mailman-version: 2.1.12 list-post: list-archive: list-id: DISPATCH Working Group Mail List x-beenthere: dispatch@ietf.org x-spam-level: x-spam-status: No, score=-110.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] x-spam-score: -110.368 x-spam-flag: NO delivered-to: dispatch@ietfa.amsl.com x-original-to: dispatch@ietfa.amsl.com x-enigmail-version: 1.4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Dispatch, With 10 days until the meeting I would like to provide a reminder on the upcoming discussion and some clarification on what we believe to be the high level question that Dispatch needs to resolve for us to be able to make progress. First of all we have not updated our drafts. They are still relevant background material for this discussion: Media Stream Selection: https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection= / Pause and Resume: https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/ The above drafts propose the need for two functionalities: Choose What Content to Receive - A media receiver wants to dynamically choose which media stream to receive, out of many possible, from a certain media sender, out of many possible Request to Pause Sending of a Content - A media receiver wants to ask the media sender to temporarily stop sending a specific media stream, and to resume it with short notice >From our perspective there exist three different high level methods for realizing this functionality: - Using a media control protocol, like BFCP or Media Control Framework - Using the media plane, like RTCP - Using the signaling plane, like SIP/SDP or other SIP carried data What we want out of the Dispatch session is clear indications on what are the most suitable method or methods (as we have two different functionalities) that should be worked out. That indication can then hopefully be turned into a decision pretty quickly to take the work to one or more WG. We want to be able to continue working on this and making progress. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --------------070609050803020802050108-- From mary.ietf.barnes@gmail.com Fri Mar 16 10:19:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9E221F86C1 for ; Fri, 16 Mar 2012 10:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+WpLMuQO0b1 for ; Fri, 16 Mar 2012 10:19:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A46F021F86B7 for ; Fri, 16 Mar 2012 10:19:22 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so205082vbb.31 for ; Fri, 16 Mar 2012 10:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yw5p9+Ey/GGRuOAjBU/u5yhB4/40q+UHk1LivUJYh3w=; b=Vx+0R6PAswDvLzUDcE4EHbhXViYdP738PMeswAek0EJEjxgHDpU6PbSkbBEeAVGMpK xZtyT/H9fcyoRqZuvkKP3PI1g9kS73XtE1w8uMwzmENw+SqkjpxVLPGPxyHcExtonJ0X 0KNEhZoQxrssFx1yCUFPQJFc16kdIxGO8Wd6TdUzgk/WQXWxUOzBHchr1LlIp5aYQM7W kBKvrB/uklqVaPcQTWHwnNSLCYfcxkToFPSpPxCbIiIion8zH0Gvcy5Z7gpOCkkXR+Zw NduGwOouyBH1Bm5bHfT/JnvTNrvPYp62CPTgRF7xISQvusOvR9rCFCBkgc3xW/FBVo3D PVpw== MIME-Version: 1.0 Received: by 10.220.115.82 with SMTP id h18mr603066vcq.18.1331918362147; Fri, 16 Mar 2012 10:19:22 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Fri, 16 Mar 2012 10:19:22 -0700 (PDT) Date: Fri, 16 Mar 2012 12:19:22 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d043c7c78d879f204bb5f68b8 Subject: [clue] Please consider attending the MMUSIC and AVTCORE WG sessions on Monday X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:19:23 -0000 --f46d043c7c78d879f204bb5f68b8 Content-Type: text/plain; charset=ISO-8859-1 There are drafts that are relevant to CLUE (including the ones that Magnus highlighted) in MMUSIC and AVTCORE on Monday, so you might want to consider attending those sessions. http://www.ietf.org/proceedings/83/agenda/agenda-83-mmusic.htm http://www.ietf.org/proceedings/83/agenda/agenda-83-avtcore.html Mary. --f46d043c7c78d879f204bb5f68b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are drafts that are relevant to CLUE (including the ones that Magnus = highlighted) in MMUSIC and AVTCORE on Monday, so you might want to consider= attending those sessions.


Mary.=A0
--f46d043c7c78d879f204bb5f68b8-- From mary.ietf.barnes@gmail.com Mon Mar 19 12:33:32 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0752D21F8872 for ; Mon, 19 Mar 2012 12:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYPHrv38SRno for ; Mon, 19 Mar 2012 12:33:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 66BD521F8871 for ; Mon, 19 Mar 2012 12:33:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so887480vbb.31 for ; Mon, 19 Mar 2012 12:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=XXiDgwDop9+qMuXxdMzyDqjRr2Oa9nyNZzrNum9hs78=; b=hb67+rmL3CBzKxI+CL974rmSl56FBaV1E60MJKRoM1QCH0r0ttFWsV1SD3Qt3WdrWK Atjf410YmagtcV5jbYm2yRBdo14gdf9JrjPFNsGHsGr5SY3i1pI05l5YD0gsP8mUZiNj MWaqIQabaqFseM5jt2EjUl/gqmN9PQT/UUEd5C18QQUx9UrQ9divPeNh47qe4uiPTHWc Xh9vPIxRcs7KmO+VJTVqVbAW2VDM80VPo3RkYhliHUy7GilExKzGpfagdCiUfEDcaCWM lIiV5ZVE9Wk8PZIigHQ+wVw1C2zMQRy1mn5w3JSw1QAR3Hm45ucdAi/0H0xvXSSkmSyC DxGQ== MIME-Version: 1.0 Received: by 10.52.28.4 with SMTP id x4mr5691127vdg.4.1332185610703; Mon, 19 Mar 2012 12:33:30 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Mon, 19 Mar 2012 12:33:30 -0700 (PDT) Date: Mon, 19 Mar 2012 14:33:30 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf30780c8419d2bf04bb9da2cf Subject: [clue] No design team call tomorrow - Tuesday, March 20th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:33:32 -0000 --20cf30780c8419d2bf04bb9da2cf Content-Type: text/plain; charset=ISO-8859-1 We had not heard back that there is interest in a call tomorrow - we've just heard that some folks won't be available. So, we will not have a call tomorrow and we'll see you all next Tuesday morning in the CLUE WG session. Thanks, Mary. On Mon, Mar 12, 2012 at 8:18 PM, Mary Barnes wrote: > Since everyone has been very busy updating docs, I'm not sure that there > is value in a call tomorrow. We could have one on the 20th if folks think > that would be useful. Please let the chairs know if you think it would be > worthwhile to discuss a particular topic before the interim. > > Thanks, > Mary. > --20cf30780c8419d2bf04bb9da2cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We had not heard back that there is interest in a call tomorrow - we've= just heard that some folks won't be available. So, we will not have a = call tomorrow and we'll see you all next Tuesday morning in the CLUE WG= session.

Thanks,
Mary.=A0

On Mon, Mar 12, 2012 at 8:18 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Since everyone has been very busy updating d= ocs, I'm not sure that there is value in a call tomorrow. =A0 We could = have one on the 20th if folks think that would be useful. =A0Please let the= chairs know if you think it would be worthwhile to discuss a particular to= pic before the interim.

Thanks,
Mary.=A0

--20cf30780c8419d2bf04bb9da2cf-- From mary.ietf.barnes@gmail.com Mon Mar 19 12:41:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBD221E801C for ; Mon, 19 Mar 2012 12:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.477 X-Spam-Level: X-Spam-Status: No, score=-103.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4kNwn0GQruI for ; Mon, 19 Mar 2012 12:41:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2619721E8015 for ; Mon, 19 Mar 2012 12:40:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so890463vbb.31 for ; Mon, 19 Mar 2012 12:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7kiPRUYs4yHeoLLeoETMbjnAh0SXqcyEMnGwUShl3DM=; b=fViBTjmojywjM0s7T8xXCm5jASNRsP+CfHFvBR5GG6ZJVUw0EUBNZAACwINENXkEG/ cnk51PAKYhDgvMIBxqAd0tK6O2p1hMfoW0r4ftRDT7DFILi5n7h5YofReEfhbkOGHgIx IrqG+b9vnu3fFz17DxO2k7yP0qTp5Gg1h+akSIMf3AGvz5hFJwW8KfT20mzJVIZQsiQD ZBCd4sfCS4mMqRyd8FObSiHDjYx0MTMw3nPpOkMvnihYVJLqxbK04JrxPxed3Zjbdg+Y xntSZl3unM4a3qEZbHS5WT5nkFM8MCcDwfLlOy84F+LtFc70oxSmtJjmundtSwapOx8Q Uglg== MIME-Version: 1.0 Received: by 10.52.28.200 with SMTP id d8mr5670266vdh.38.1332186059654; Mon, 19 Mar 2012 12:40:59 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Mon, 19 Mar 2012 12:40:59 -0700 (PDT) Date: Mon, 19 Mar 2012 14:40:59 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3079bc9edc46a804bb9dbcf4 Subject: [clue] Updates to agenda & deadline for meeting materials X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 19:41:01 -0000 --20cf3079bc9edc46a804bb9dbcf4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We revised the agenda and switched the slots for the SDP/signaling and RTP discussions: http://www.ietf.org/proceedings/83/agenda/agenda-83-clue.html The latter will now be on Tuesday morning and the former on Thursday afternoon. The chairs will need the materials for the presentations no later than Friday, March 23rd at noon Pacific for the Tuesday slot and no later than noon Paris time on Sunday for the Thursday slot. This will allow the chairs time to review and upload the materials to allow folks to review the material before the meeting. Also, please consider attending the MMUSIC and AVTCORE WG sessions on Monday - there will be discussion of drafts related to multi-stream that may apply to CLUE. In addition, there will be some drafts discussed that may also be interest in the DISPATCH WG session on Tuesday afternoon. Regards, Mary CLUE WG co-chair --20cf3079bc9edc46a804bb9dbcf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

We revised the agenda and switched the slots for= the SDP/signaling and RTP discussions:
The latter will now be on Tuesday morning and the former on Thursday a= fternoon.=A0

The chairs will need the materials fo= r the presentations no later than Friday, March 23rd at noon Pacific for th= e Tuesday slot and no later than noon Paris time on Sunday for the Thursday= slot. =A0This will allow the chairs time to review and upload the material= s to allow folks to review the material before the meeting. =A0

Also, please consider attending the MMUSIC and AVTCORE = WG sessions on Monday - there will be discussion of drafts related to multi= -stream that may apply to CLUE. =A0 In addition, there will be some drafts = discussed that may also be interest in the DISPATCH WG session on Tuesday a= fternoon.=A0

Regards,
Mary=A0
CLUE WG co-chair --20cf3079bc9edc46a804bb9dbcf4-- From Mark.Duckworth@polycom.com Mon Mar 19 15:05:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D3A21F86DC for ; Mon, 19 Mar 2012 15:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.785 X-Spam-Level: X-Spam-Status: No, score=-5.785 tagged_above=-999 required=5 tests=[AWL=-0.676, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MivnjmtWM4fc for ; Mon, 19 Mar 2012 15:05:21 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2121F86D9 for ; Mon, 19 Mar 2012 15:05:21 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 19 Mar 2012 15:05:20 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 19 Mar 2012 15:05:18 -0700 Thread-Topic: Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8Wg== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FCA3092ACRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:05:23 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCA3092ACRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a follow on to the email thread with subject 'propose "mutually exc= lusive" attribute to replace simutaneous sets'. It seemed like that thread= didn't have any agreement. So I'll suggest a simpler change to see what y= ou think. This is motivated by a discussion at the interim meeting where I= thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with "simultaneous sets", do it instead with "mutually ex= clusive sets". The purpose is to have a more concise way to indicate which= media captures cannot be used at the same time, which we believe scales be= tter than the simultaneous set idea when there are multiple mutually exclus= ive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can't be used= at the same time. And VC3 and VC4 can't be used at the same time. And VC= 5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCA3092ACRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a follow= on to the email thread with subject ‘propose "mutually exclusiv= e" attribute to replace simutaneous sets’.  It seemed like = that thread didn’t have any agreement.  So I’ll suggest a = simpler change to see what you think.  This is motivated by a discussi= on at the interim meeting where I thought a few people were in favor of thi= s.

 

Instead of conveying the information about which media captures can be= used at the same time with “simultaneous sets”, do it instead = with “mutually exclusive sets”.  The purpose is to have a = more concise way to indicate which media captures cannot be used at the sam= e time, which we believe scales better than the simultaneous set idea when = there are multiple mutually exclusive constraints.

 

Here is an example o= f the difference.  Suppose a provider is advertising six video capture= s.  The provider wants to say that VC1 and VC2 can’t be used at = the same time.  And VC3 and VC4 can’t be used at the same time.&= nbsp; And VC5 and VC6 can’t be used at the same time.

<= p class=3DMsoNormal> 

In simultaneous sets it would be expressed like this:

{VC1,= VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}=

{V= C2, VC3, VC6}

{VC2, VC4, VC6}

&= nbsp;

With mutually exclusive sets, it would = be expressed like this:

{VC1, VC2}<= /o:p>

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage or disadvantage to this?<= /o:p>

 

Mar= k

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCA3092ACRPMBOXPRD01p_-- From allyn@cisco.com Mon Mar 19 20:44:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E06A21E8043 for ; Mon, 19 Mar 2012 20:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0RvkG1v2ppb for ; Mon, 19 Mar 2012 20:44:47 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9047D21E8012 for ; Mon, 19 Mar 2012 20:44:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=8147; q=dns/txt; s=iport; t=1332215087; x=1333424687; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=ZaERaGt31COQXBA0m6Z7mG9kUFMY3zyifM23VpEoGuo=; b=bITbk6OTUi3XeJB6dN3WPbnFzOW8xiI/gRZaiFaWW/AgHYqdhd6Tk8cw IwXYjDw2yW+cloY2+X9iJyufv2zoGqrZmHFVp8OuZIaQeCKLMNSAghtpg d0Kpe0p6+5Rn/1Rq9wouQtmKDyfQ6EhVjBvDSTSklaYtkibYLM5aseQUU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAC/8Z0+rRDoH/2dsb2JhbABBgka0C4EHggkBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHZwGYV58Vj35jBIhWm0iBaIMGgTw X-IronPort-AV: E=Sophos;i="4.73,616,1325462400"; d="scan'208,217";a="33708929" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 20 Mar 2012 03:44:47 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2K3iliD011655; Tue, 20 Mar 2012 03:44:47 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 20:44:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD064B.CB182D1C" Date: Mon, 19 Mar 2012 20:44:41 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC070CFF6B@xmb-sjc-221.amer.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgADCH7A References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> From: "Allyn Romanow (allyn)" To: "Duckworth, Mark" , X-OriginalArrivalTime: 20 Mar 2012 03:44:46.0877 (UTC) FILETIME=[CB6BDCD0:01CD064B] Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 03:44:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD064B.CB182D1C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi- It seems that the advantage is it's more parsimonious and I don't see any disadvantages. =20 Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 19, 2012 3:05 PM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? =20 This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. =20 Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. =20 Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. =20 In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} =20 Does anybody see any advantage or disadvantage to this? =20 Mark ------_=_NextPart_001_01CD064B.CB182D1C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi-

It seems that the = advantage is it’s more parsimonious and I don’t see any = disadvantages.

 

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Monday, March 19, 2012 3:05 PM
To: clue@ietf.org
Subject: [clue] Simultaneous set, or mutually exclusive = set?

 

This is a follow on to the email thread with = subject ‘propose "mutually exclusive" attribute to replace = simutaneous sets’.  It seemed like that thread didn’t have any agreement.  So I’ll suggest a simpler change to see what you think.  This is motivated by a discussion at the interim meeting = where I thought a few people were in favor of this.

 

Instead of conveying the information about which = media captures can be used at the same time with “simultaneous = sets”, do it instead with “mutually exclusive sets”.  The purpose = is to have a more concise way to indicate which media captures cannot be used = at the same time, which we believe scales better than the simultaneous set idea = when there are multiple mutually exclusive constraints.

 

Here is an example of the difference.  Suppose = a provider is advertising six video captures.  The provider wants to = say that VC1 and VC2 can’t be used at the same time.  And VC3 and = VC4 can’t be used at the same time.  And VC5 and VC6 can’t = be used at the same time.

 

In simultaneous sets = it would be expressed like this:

{VC1, VC3, = VC5}

{VC1, VC4, = VC5}

{VC1, VC3, = VC6}

{VC1, VC4, = VC6}

{VC2, VC3, = VC5}

{VC2, VC4, = VC5}

{VC2, VC3, = VC6}

{VC2, VC4, = VC6}

 

With mutually exclusive sets, it would be expressed = like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage or disadvantage to = this?

 

Mark

------_=_NextPart_001_01CD064B.CB182D1C-- From Mark.Duckworth@polycom.com Wed Mar 21 08:16:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDDF21F8751 for ; Wed, 21 Mar 2012 08:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HChMrIRagkxk for ; Wed, 21 Mar 2012 08:16:34 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4621F874C for ; Wed, 21 Mar 2012 08:16:27 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 21 Mar 2012 08:16:27 -0700 From: "Duckworth, Mark" To: Roni Even , "clue@ietf.org" Date: Wed, 21 Mar 2012 08:16:25 -0700 Thread-Topic: [clue] switch-policy attribute proposal Thread-Index: Acz7CVVv4KEEqhZGQBGw2/oY+gJ9ZQAaTL+QAwCSadA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60561@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FB6C805B@CRPMBOXPRD01.polycom.com> <4f55caec.cf5e0e0a.5211.ffffd6f2@mx.google.com> In-Reply-To: <4f55caec.cf5e0e0a.5211.ffffd6f2@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60561CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] switch-policy attribute proposal X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:16:36 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60561CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks for the suggestions, I agree. When I looked back at section 3.3 Multipoint meeting in the use cases, I se= e it gives a good description of site switch, segment switch, and also desc= ribes a possibility with neither of those, for example using continuous pre= sence without switching. It seems to make sense to change this proposal a bit, to better match the u= se case. I think the point of this attribute is about the whole scene, not= just a particular media capture. So maybe the attribute should be named "= scene-switch-policy" (rather than "switch-policy") and values could still b= e {site-switch, segment-switch}. If the provider wants to advertise a capt= ure scene entry that is neither site-switch nor segment-switch, it should = just omit this attribute. What do you think? I agree with you we should make it clear that this attribute is about the p= olicy of coordinating multiple captures in a capture scene entry, not about= the criteria for deciding when to switch something. If the group generall= y agrees with all this, I could update the proposal with more specific text= . Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, March 06, 2012 3:28 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] switch-policy attribute proposal Mark, I am OK with this. I assume this applies to the multipoint case, maybe add = a reference to the relevant use case in the use case draft. I am not sure about the attribute name since there is no intent to make it = the general switch case for example "voice activated", "round robin" Maybe change the attribute name to TP-switch-policy and emphasis the purpos= e of the attribute. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Monday, March 05, 2012 9:51 PM To: clue@ietf.org Subject: [clue] switch-policy attribute proposal At the interim meeting I think people generally agreed the clue framework s= hould include a way for a provider to advertise site-switching and segment-= switching policies, and for the consumer to request one or the other. Here= is a rough proposal. Add a new "switch-policy" attribute for a capture scene entry (or capture s= et entry, using the framework-03 terminology) (note the attribute is for a = capture scene entry not a media capture). Switch-policy: {site-switch, segment-switch} An attribute with enumerated values which identifies the policy the provide= r uses for how to switch the various media captures within the capture scen= e entry. A value of 'site-switch' means all the media captures within the capture sc= ene entry typically switch together, with the provider attempting to includ= e all the media captures from the same site together. A value of 'segment-switch' means the media captures in the entry switch in= dependently of each other, so at any point in time the media captures could= be originally sourced from different sites. In a provider advertisement, the provider can include multiple values for t= he switch-policy attribute. The provider is saying it can provide any one = of those switch-policies it advertises. When a consumer configures the pro= vider, the consumer includes this attribute with only the single value for = switch-policy that it wants to receive. Regards, Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60561CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thanks for the suggestions, I agree.

 =

When I looked= back at section 3.3 Multipoint meeting in the use cases, I see it gives a = good description of site switch, segment switch, and also describes a possi= bility with neither of those, for example using continuous presence without= switching.

 

It seems to make sense to change this proposal a bit, to bette= r match the use case.  I think the point of this attribute is about th= e whole scene, not just a particular media capture.  So maybe the attr= ibute should be named “scene-switch-policy” (rather than “= ;switch-policy”) and values could still be {site-switch, segment-swit= ch}.  If the provider wants to advertise a capture scene entry that is= neither site-switch nor segment-switch,  it should just omit this att= ribute.  What do you think?

=  

I agree with you we should make it clear = that this attribute is about the policy of coordinating multiple captures i= n a capture scene entry, not about the criteria for deciding when to switch= something.  If the group generally agrees with all this, I could upda= te the proposal with more specific text.

 

Mark

 

Fro= m: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Tuesday, M= arch 06, 2012 3:28 AM
To: Duckworth, Mark; clue@ietf.org
Su= bject: RE: [clue] switch-policy attribute proposal

 

Mark,

I am OK with this. I assume this applies = to the multipoint case, maybe add a reference to the relevant use case in t= he use case draft.

 

I am not sure about the attribute name since there is n= o intent to make it the general switch case for example "voice activat= ed", "round robin"

Maybe change the attribute name to TP-switch= -policy and emphasis the purpose of the attribute.

 

Roni<= /p>

 

From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Se= nt: Monday, March 05, 2012 9:51 PM
To: clue@ietf.org
Su= bject: [clue] switch-policy attribute proposal

 

At = the interim meeting I think people generally agreed the clue framework shou= ld include a way for a provider to advertise site-switching and segment-swi= tching policies, and for the consumer to request one or the other.  He= re is a rough proposal.

 

Add a new “switch-policy” attribute f= or a capture scene entry (or capture set entry, using the framework-03 term= inology) (note the attribute is for a capture scene entry not a media captu= re).

 

Switch-policy: {site-switch, segment-switch}

An attribute with enumerated values which identifies the polic= y the provider uses for how to switch the various media captures within the= capture scene entry.

A value of ‘= site-switch’ means all the media captures within the capture scene en= try typically switch together, with the provider attempting to include all = the media captures from the same site together.

A value of ‘segment-switch’ means the media captures in= the entry switch independently of each other, so at any point in time the = media captures could be originally sourced from different sites.=

 

In a pro= vider advertisement, the provider can include multiple values for the switc= h-policy attribute.  The provider is saying it can provide any one of = those switch-policies it advertises.  When a consumer configures the p= rovider, the consumer includes this attribute with only the single value fo= r switch-policy that it wants to receive.

 

Regards,

Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60561CRPMBOXPRD01p_-- From apeppere@gmail.com Wed Mar 21 10:21:45 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D331121E8055 for ; Wed, 21 Mar 2012 10:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4aqhC5Wbvef for ; Wed, 21 Mar 2012 10:21:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA65A21E801A for ; Wed, 21 Mar 2012 10:21:42 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1499598vcb.31 for ; Wed, 21 Mar 2012 10:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1cYtBJTzbOtTNicvG2hqtc7mgZx8aEhepJCGvOl+XDM=; b=jBgUM1UX4YnmClyAaFasGp3z39ifiW8U2GiU+eEqBfn3DoKDTGVT1PaY4wHS2PfNa4 dgoaA3UG6CBFDZWlXOi50+oLHLz1H+GdPbKdZ3KkLqoFlMaX5a+FvnpzE5HAK5XrBPSq 7k7AMbZBr9Bon/qYxL1Mzo8x6R41TVBtODCdx5akiXpN7eVTs/+SfpGgnrnn7av7ddWE DYRiplQKAVR0nWg8Yhl4PMaR9u7EdqNh0TFC17KiZmLDrKsju8aUQoRCTnOND3EWWdaZ OsEAQ6y+2S87jTWx9Qi4QtDaVLsGS30iNjIqHm+Be61k/xDnWFuvu0p8SyMU653ON9PS APRQ== MIME-Version: 1.0 Received: by 10.52.179.74 with SMTP id de10mr1953593vdc.12.1332350500280; Wed, 21 Mar 2012 10:21:40 -0700 (PDT) Received: by 10.220.84.205 with HTTP; Wed, 21 Mar 2012 10:21:40 -0700 (PDT) Date: Wed, 21 Mar 2012 17:21:40 +0000 Message-ID: From: Andy Pepperell To: clue@ietf.org Content-Type: multipart/alternative; boundary=bcaec5171e2949181804bbc40697 Subject: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 17:21:45 -0000 --bcaec5171e2949181804bbc40697 Content-Type: text/plain; charset=ISO-8859-1 All, The framework author team have been having a few discussions recently on the topic of the proposed "composed" attribute, with a view to clearing up our own and the wider group's confusion on this topic, and I thought it would be useful to set out our current position here: The original intent behind this attribute was to allow a media stream consumer to distinguish between "natural" media (such as something that could be viewed by a lens or human eye within a room) and "artificial" media (such as a 2x2 composed layout generated by an MCU-style middle box). The main need for this distinction was deemed to be the case where the consumer was itself a middle box / MCU intending to form its own multi-pane compositions, either through transcoding or by forwarding on switched "loudest speaker" streams. In these cases, such devices would want to avoid already-composed video captures (or, more specifically, any capture scene entries with one or more captures so tagged). With more thought on this, we also came to the conclusion that the use for this attribute for video captures doesn't necessarily translate exactly equivalently to audio captures. In a network of cascaded MCUs it *would* often be perfectly acceptable to use a pre-mixed audio stream from a peer MCU whereas it would be highly desirable to not use pre-composed, multi-pane, video from those media providers. Largely because of the potential different use of the attribute by media stream consumers, our thinking is that we *shouldn't* define the "composed" attribute to apply to both video and audio captures, and instead use, if required, a separate "mixed" attribute for the audio case. For the video aspect of this same scenario (i.e. a 3 camera room), we'd see neither the 3 separate camera video captures nor a zoomed out central camera needing the "composed" attribute. A case where a video capture would be tagged as "composed" in this scenario would be where the endpoint was sending a single video capture formed of the loudest panel plus, say, a small version of all 3 cameras' streams superimposed on the image. For the specific case of a 3 microphone room which can either provide 3 separate streams to the far end or a single pre-mixed audio stream, we'd anticipate none of these audio captures necessarily being tagged as "mixed", as this expresses no more information than is provided by the fact that the 3 capture entry and single capture entry appear as equivalents in the same capture scene. Hope this clarification is useful (or at least promotes some more healthy debate :) ) Andy --bcaec5171e2949181804bbc40697 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

The framework author team have been having a = few discussions recently on the topic of the proposed "composed" = attribute, with a view to clearing up our own and the wider group's con= fusion on this topic, and I thought it would be useful to set out our curre= nt position here:

The original intent behind this attribute was to allow a med= ia stream consumer to distinguish between "natural" media (such a= s something that could be viewed by a lens or human eye within a room) and = "artificial" media (such as a 2x2 composed layout generated by an= MCU-style middle box). The main need for this distinction was deemed to be= the case where the consumer was itself a middle box / MCU intending to for= m its own multi-pane compositions, either through transcoding or by forward= ing on switched "loudest speaker" streams. In these cases, such d= evices would want to avoid already-composed video captures (or, more specif= ically, any capture scene entries with one or more captures so tagged).

With more thought on this, we also came to the conclusi= on that the use for this attribute for video captures doesn't necessari= ly translate exactly equivalently to audio captures. In a network of cascad= ed MCUs it *would* often be perfectly acceptable to use a pre-mixed audio s= tream from a peer MCU whereas it would be highly desirable to not use pre-c= omposed, multi-pane, video from those media providers. Largely because of t= he potential different use of the attribute by media stream consumers, our = thinking is that we *shouldn't* define the "composed" attribu= te to apply to both video and audio captures, and instead use, if required,= a separate "mixed" attribute for the audio case.

For the video aspect of this same scenario (i.e. a 3 ca= mera room), we'd see neither the 3 separate camera video captures nor a= zoomed out central camera needing the "composed" attribute. A ca= se where a video capture would be tagged as "composed" in this sc= enario would be where the endpoint was sending a single video capture forme= d of the loudest panel plus, say, a small version of all 3 cameras' str= eams superimposed on the image.

For the specific case of a 3 microphone room which can = either provide 3 separate streams to the far end or a single pre-mixed audi= o stream, we'd anticipate none of these audio captures necessarily bein= g tagged as "mixed", as this expresses no more information than i= s provided by the fact that the 3 capture entry and single capture entry ap= pear as equivalents in the same capture scene.

Hope this clarification is useful (or at least promotes= some more healthy debate :) )

Andy

=
--bcaec5171e2949181804bbc40697-- From ron.even.tlv@gmail.com Wed Mar 21 11:33:28 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F0321E8097 for ; Wed, 21 Mar 2012 11:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PbtLq8RxMTL for ; Wed, 21 Mar 2012 11:33:28 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A4F6121E8054 for ; Wed, 21 Mar 2012 11:33:27 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so1494173wib.13 for ; Wed, 21 Mar 2012 11:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=INAlt1HherVmEA3QyMbR3lk9nKcmrBuYS47lKDUtylo=; b=FyrdQJvN/AHX+WwjBwlW5A/rHHma+7hbvjDuW1Vg8RELNhZNfh1eXTMWc+qx88boSo Pa3Exo9nRzGuTIf//7J8OIZlrTG96g2QGjU4OVa/DIMkOuI1/CjIOVdJBqzooqACXuRl cz62Rh6d8oAtdMfrVc6H2SohpYGJBCWQyOpN6kaEWiRRgu/HUGtJAAbtkHweUaiclC2B SuG7MeO7PTvi6CJNf9pt7uXBLTqsF/7Mt7HpH+WCZWgY12EyT7GtdfQf5O0V/ZqbAo0S V5TID5bdDYEUPpoRDP6wrABMZn1HbASuCkqhL9Q6CAV0h+20flrZ/de22Zc7wW1S6nRu iOCg== Received: by 10.180.19.196 with SMTP id h4mr11490700wie.12.1332354806874; Wed, 21 Mar 2012 11:33:26 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id ex2sm10483504wib.8.2012.03.21.11.33.24 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 11:33:25 -0700 (PDT) From: "Roni Even" To: "'Andy Pepperell'" , References: In-Reply-To: Date: Wed, 21 Mar 2012 20:32:23 +0200 Message-ID: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C7_01CD07A1.BA157570" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0Hhx4Q4sEAMfKISnGkPhV851aGqAABmjrg Content-Language: en-us Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 18:33:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02C7_01CD07A1.BA157570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Andy, I am not sure what is the issue since the MCU knows if this is an audio or video stream and can handle them differently like all MCUs will do today. For cascading there is a need to know if the consumer is an MCU in order to advertise the right information. This may still be a composed video from the end point (like current speaker mixed with pip of others) but not composed from an MCU. I am not sure why you do not want to have the mixed audio from the room as mixed. How do you know if it is mixed or just a pickup of the whole room by one microphone from the three if both advertisements will have the whole room co-ordinates, and like I said above the consumer will know if this is audio or video and how to handle it. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Andy Pepperell Sent: Wednesday, March 21, 2012 7:22 PM To: clue@ietf.org Subject: [clue] Use of the media capture "composed" attribute All, The framework author team have been having a few discussions recently on the topic of the proposed "composed" attribute, with a view to clearing up our own and the wider group's confusion on this topic, and I thought it would be useful to set out our current position here: The original intent behind this attribute was to allow a media stream consumer to distinguish between "natural" media (such as something that could be viewed by a lens or human eye within a room) and "artificial" media (such as a 2x2 composed layout generated by an MCU-style middle box). The main need for this distinction was deemed to be the case where the consumer was itself a middle box / MCU intending to form its own multi-pane compositions, either through transcoding or by forwarding on switched "loudest speaker" streams. In these cases, such devices would want to avoid already-composed video captures (or, more specifically, any capture scene entries with one or more captures so tagged). With more thought on this, we also came to the conclusion that the use for this attribute for video captures doesn't necessarily translate exactly equivalently to audio captures. In a network of cascaded MCUs it *would* often be perfectly acceptable to use a pre-mixed audio stream from a peer MCU whereas it would be highly desirable to not use pre-composed, multi-pane, video from those media providers. Largely because of the potential different use of the attribute by media stream consumers, our thinking is that we *shouldn't* define the "composed" attribute to apply to both video and audio captures, and instead use, if required, a separate "mixed" attribute for the audio case. For the video aspect of this same scenario (i.e. a 3 camera room), we'd see neither the 3 separate camera video captures nor a zoomed out central camera needing the "composed" attribute. A case where a video capture would be tagged as "composed" in this scenario would be where the endpoint was sending a single video capture formed of the loudest panel plus, say, a small version of all 3 cameras' streams superimposed on the image. For the specific case of a 3 microphone room which can either provide 3 separate streams to the far end or a single pre-mixed audio stream, we'd anticipate none of these audio captures necessarily being tagged as "mixed", as this expresses no more information than is provided by the fact that the 3 capture entry and single capture entry appear as equivalents in the same capture scene. Hope this clarification is useful (or at least promotes some more healthy debate :) ) Andy ------=_NextPart_000_02C7_01CD07A1.BA157570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

I am not sure what is the issue since the MCU knows if this is an = audio or video stream and can handle them differently like all MCUs will = do today. For cascading there is a need to know if the consumer is an = MCU in order to advertise  the right information. This may still be = a composed video from the end point (like current speaker mixed with pip = of others) but not composed from an MCU.

 

I am not sure why you do not want to have the mixed audio from the = room as mixed. How do you know if it is mixed or just a pickup of the = whole room by one microphone from the three if both advertisements will = have the whole room co-ordinates, and like I said above the consumer = will know if this is audio or video and how to handle = it.

 

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Andy Pepperell
Sent: Wednesday, March 21, 2012 7:22 = PM
To: clue@ietf.org
Subject: [clue] Use of the = media capture "composed" = attribute

 

All,

 

The = framework author team have been having a few discussions recently on the = topic of the proposed "composed" attribute, with a view to = clearing up our own and the wider group's confusion on this topic, and I = thought it would be useful to set out our current position = here:

 

The original intent behind this attribute was to allow = a media stream consumer to distinguish between "natural" media = (such as something that could be viewed by a lens or human eye within a = room) and "artificial" media (such as a 2x2 composed layout = generated by an MCU-style middle box). The main need for this = distinction was deemed to be the case where the consumer was itself a = middle box / MCU intending to form its own multi-pane compositions, = either through transcoding or by forwarding on switched "loudest = speaker" streams. In these cases, such devices would want to avoid = already-composed video captures (or, more specifically, any capture = scene entries with one or more captures so = tagged).

 

With more thought on this, we also came to the = conclusion that the use for this attribute for video captures doesn't = necessarily translate exactly equivalently to audio captures. In a = network of cascaded MCUs it *would* often be perfectly acceptable to use = a pre-mixed audio stream from a peer MCU whereas it would be highly = desirable to not use pre-composed, multi-pane, video from those media = providers. Largely because of the potential different use of the = attribute by media stream consumers, our thinking is that we *shouldn't* = define the "composed" attribute to apply to both video and = audio captures, and instead use, if required, a separate = "mixed" attribute for the audio = case.

 

For the video aspect of this same scenario (i.e. a 3 = camera room), we'd see neither the 3 separate camera video captures nor = a zoomed out central camera needing the "composed" attribute. = A case where a video capture would be tagged as "composed" in = this scenario would be where the endpoint was sending a single video = capture formed of the loudest panel plus, say, a small version of all 3 = cameras' streams superimposed on the image.

 

For the specific case of a 3 microphone room which can = either provide 3 separate streams to the far end or a single pre-mixed = audio stream, we'd anticipate none of these audio captures necessarily = being tagged as "mixed", as this expresses no more information = than is provided by the fact that the 3 capture entry and single capture = entry appear as equivalents in the same capture = scene.

 

Hope this clarification is useful (or at least = promotes some more healthy debate :) )

 

Andy

 

------=_NextPart_000_02C7_01CD07A1.BA157570-- From espeberg@cisco.com Wed Mar 21 13:05:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959AA21E80EE for ; Wed, 21 Mar 2012 13:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.238 X-Spam-Level: X-Spam-Status: No, score=-10.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMoydRcKSqPO for ; Wed, 21 Mar 2012 13:05:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 272AE21E80E9 for ; Wed, 21 Mar 2012 13:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=10742; q=dns/txt; s=iport; t=1332360325; x=1333569925; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=oxZNGvosXPWOWa3QiBcL2vKJFrso+f1AvBso5ANlbmI=; b=iwWugAF3QP3/wNNBzR1PdHYNJCphpc/h1QbhQBxcRKm1sezvkIzzgl3i hF6povv5Ag/M49OjM/+J7vTaWfLPtam8XdyIuQZ/F1NB7qbxOqu1WPDRR 6Yinf2MZWmMQExG+pUNltW55SO4S2lQkpoHybkd79KDSTNyDsfeHZil/s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEw0ak+Q/khM/2dsb2JhbABEgka0Q4EHggkBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHaJkGnwKQHmMEpB6BaIJogVs X-IronPort-AV: E=Sophos;i="4.73,624,1325462400"; d="scan'208,217";a="132988616" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2012 20:05:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2LK5BO7021173; Wed, 21 Mar 2012 20:05:11 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 21:05:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD079D.EBE505B8" Date: Wed, 21 Mar 2012 21:05:10 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E0109C846@XMB-AMS-214.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC070CFF6B@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgADCH7AAF2sC5A= References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC070CFF6B@xmb-sjc-221.amer.cisco.com> From: "Espen Berger (espeberg)" To: "Allyn Romanow (allyn)" , "Duckworth, Mark" , X-OriginalArrivalTime: 21 Mar 2012 20:05:11.0620 (UTC) FILETIME=[EC1D1040:01CD079D] Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:05:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD079D.EBE505B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The mutually exclusive set are easier to understand and more compact as listed in the example.=20 =20 -Espen=20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) Sent: 20. mars 2012 04:45 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? =20 Hi- It seems that the advantage is it's more parsimonious and I don't see any disadvantages. =20 Allyn =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Monday, March 19, 2012 3:05 PM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? =20 This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. =20 Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. =20 Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. =20 In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} =20 Does anybody see any advantage or disadvantage to this? =20 Mark ------_=_NextPart_001_01CD079D.EBE505B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The mutually exclusive set are easier to = understand and more compact as listed in the example. =

 

-Espen =

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Allyn Romanow (allyn)
Sent: 20. mars 2012 = 04:45
To: Duckworth, Mark; clue@ietf.org
Subject: = Re: [clue] Simultaneous set, or mutually exclusive = set?

 

Hi-

It seems = that the advantage is it’s more parsimonious and I don’t see = any disadvantages.

 

Allyn

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Monday, March 19, = 2012 3:05 PM
To: clue@ietf.org
Subject: = [clue] Simultaneous set, or mutually exclusive = set?

 

This is a follow on to the email thread with subject = ‘propose "mutually exclusive" attribute to replace = simutaneous sets’.  It seemed like that thread didn’t = have any agreement.  So I’ll suggest a simpler change to see = what you think.  This is motivated by a discussion at the interim = meeting where I thought a few people were in favor of = this.

 

Instead of conveying the information about which media = captures can be used at the same time with “simultaneous = sets”, do it instead with “mutually exclusive = sets”.  The purpose is to have a more concise way to indicate = which media captures cannot be used at the same time, which we believe = scales better than the simultaneous set idea when there are multiple = mutually exclusive constraints.

 

Here is an example of the = difference.  Suppose a provider is advertising six video = captures.  The provider wants to say that VC1 and VC2 can’t = be used at the same time.  And VC3 and VC4 can’t be used at = the same time.  And VC5 and VC6 can’t be used at the same = time.

 

In simultaneous sets it would be = expressed like this:

{VC1, VC3, = VC5}

{VC1, VC4, VC5}

{VC1, VC3, = VC6}

{VC1, VC4, VC6}

{VC2, VC3, = VC5}

{VC2, VC4, VC5}

{VC2, VC3, = VC6}

{VC2, VC4, VC6}

 

With mutually exclusive sets, it = would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage or = disadvantage to this?

 

Mark

------_=_NextPart_001_01CD079D.EBE505B8-- From john@jlc.net Wed Mar 21 13:23:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF6321E8111 for ; Wed, 21 Mar 2012 13:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.356 X-Spam-Level: X-Spam-Status: No, score=-106.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQNRtujwn0cc for ; Wed, 21 Mar 2012 13:23:57 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0022621E80F1 for ; Wed, 21 Mar 2012 13:23:55 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id B11D533C4F; Wed, 21 Mar 2012 16:23:55 -0400 (EDT) Date: Wed, 21 Mar 2012 16:23:55 -0400 From: John Leslie To: Roni Even Message-ID: <20120321202355.GJ79816@verdi> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 20:23:58 -0000 Roni Even wrote: > [Andy Pepperell wrote:] >> >> With more thought on this, we also came to the conclusion that the use for >> this attribute for video captures doesn't necessarily translate exactly >> equivalently to audio captures. In a network of cascaded MCUs it *would* >> often be perfectly acceptable to use a pre-mixed audio stream from a peer >> MCU whereas it would be highly desirable to not use pre-composed, >> multi-pane, video from those media providers. Largely because of the >> potential different use of the attribute by media stream consumers, our >> thinking is that we *shouldn't* define the "composed" attribute to apply to >> both video and audio captures, and instead use, if required, a separate >> "mixed" attribute for the audio case. I'm not sure it needs to be "separate", but I would hope we have a tag to show that two or more microphones in different positions were "mixed" into a single audio stream. I view this as a warning label -- and a single bit suffices unless we include details of the microphones being mixed (which I don't believe is the current plan). >> For the specific case of a 3 microphone room which can either provide 3 >> separate streams to the far end or a single pre-mixed audio stream, we'd >> anticipate none of these audio captures necessarily being tagged as "mixed", >> as this expresses no more information than is provided by the fact that the >> 3 capture entry and single capture entry appear as equivalents in the same >> capture scene. I don't understand: why wouldn't the pre-mixed stream be labeled "mixed"? > I am not sure what is the issue since the MCU knows if this is an audio or > video stream and can handle them differently like all MCUs will do today. (Use of the same bit seems OK...) > For cascading there is a need to know if the consumer is an MCU in order to > advertise the right information. This may still be a composed video from > the end point (like current speaker mixed with pip of others) but not > composed from an MCU. I don't understand Roni here: surely we can set the "composed" bit if we're sending split-screen regardless of who will receive that stream. > I am not sure why you do not want to have the mixed audio from the room as > mixed. How do you know if it is mixed or just a pickup of the whole room by > one microphone from the three if both advertisements will have the whole > room co-ordinates, Hopefully any software will know if _it_ is mixing two streams: it would have to depend on an operator to specify that one of the streams is from a mixer. Since I view this as a warning label, I'd like it to be passed on. > and like I said above the consumer will know if this is audio or video Yes. > and how to handle it. In many cases, it would be handled the same whether mixed or not; but I can imagine future enhancements which process the audio streams to different apparent positions in multi-channel audio schemes. For our first pass, it's arguably sufficient to take a single mixed audio stream for each room and process it to a stereo position. But if we receive more than one audio stream from a room, processing them to different stereo positions might help. (The actual use of a "mixed" bit, as I imagine it, would be to process the audio to a less-distinct position, and probably softer than any un-mixed audio streams from that room. If I were also adding impulse-response, I'd probably add less for a "mixed" stream. The point is, while the differences are subtle, subtle audio clues can be very helpful.) -- John Leslie From espeberg@cisco.com Wed Mar 21 14:39:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ADC21E8087 for ; Wed, 21 Mar 2012 14:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKoGKethpbrL for ; Wed, 21 Mar 2012 14:39:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB7721E8032 for ; Wed, 21 Mar 2012 14:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=1718; q=dns/txt; s=iport; t=1332365977; x=1333575577; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=QbvEEjWa5HZh7OYHHLmbj9nSpD9l2stqMmFO1yTE1nw=; b=dqovSHtkqyEsVnp5aAtisU/ny1Gyu2CQdrO4+A6azRnwsNn+mgBqxVW0 1n3MO1PWAZ0whcoo52O45Q6O8emDH02K6dlS+IfOqEb1aMQHG7t4eZB3O XQqeRHLzOnodXmj2ycKws5C8y8rV4GWBPuYiCJ2yBSf1+8VU5vr13zH5e k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGdJak+Q/khR/2dsb2JhbABEtwuBB4IJAQEBBAEBAQ8BHT4JDgQCAQgRAwEBAQsGFwEGASAGHwkIAQEEARIIGodoC5kSnweJbIYyYwSII5hqgxGBaIJo X-IronPort-AV: E=Sophos;i="4.73,624,1325462400"; d="scan'208";a="132994501" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2012 21:39:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2LLdagn018582; Wed, 21 Mar 2012 21:39:36 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 22:39:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Mar 2012 22:39:35 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E0109C85A@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Fwd: New Version Notification fordraft-wenger-clue-transport-02.txt Thread-Index: Ac0Am3Si0hf3tbu4SKmVtcECc/1+hAHDN9vg References: <20120312212830.18279.48690.idtracker@ietfa.amsl.com> From: "Espen Berger (espeberg)" To: "Marshall Eubanks" , "clue" X-OriginalArrivalTime: 21 Mar 2012 21:39:36.0167 (UTC) FILETIME=[1C725770:01CD07AB] Subject: Re: [clue] Fwd: New Version Notification fordraft-wenger-clue-transport-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:39:38 -0000 The RTCWeb group are working on defining a generic data channel based on = sctp, as defined in:=20 http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-00 It seems that the data channel suggestion from rtcweb matches CLUE = transport option 2.=20 Has the ongoing rtcweb been considered? Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Marshall Eubanks Sent: 12. mars 2012 23:00 To: clue Subject: [clue] Fwd: New Version Notification = fordraft-wenger-clue-transport-02.txt For your reading pleasure. Naturally, I have already caught a typo. Regards Marshall ---------- Forwarded message ---------- From: Date: Mon, Mar 12, 2012 at 5:28 PM Subject: New Version Notification for draft-wenger-clue-transport-02.txt To: marshall.eubanks@gmail.com Cc: ron.even.tlv@gmail.com, stewe@stewe.org, = gonzalo.camarillo@ericsson.com A new version of I-D, draft-wenger-clue-transport-02.txt has been = successfully submitted by Marshall Eubanks and posted to the IETF = repository. Filename: =A0 =A0 =A0 =A0draft-wenger-clue-transport Revision: =A0 =A0 =A0 =A002 Title: =A0 =A0 =A0 =A0 =A0 Transport Options for Clue Creation date: =A0 = 2012-03-12 WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission Number of = pages: 13 Abstract: =A0 This memo describes the assumption and the proposed options for the =A0 coding and transport of CLUE messages as outlined in version 01 of =A0 the framework draft. The IETF Secretariat _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Thu Mar 22 01:14:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126B321F857F for ; Thu, 22 Mar 2012 01:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtZwN6k8kmew for ; Thu, 22 Mar 2012 01:14:06 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02F5621F8551 for ; Thu, 22 Mar 2012 01:14:03 -0700 (PDT) Received: by werb10 with SMTP id b10so1889100wer.31 for ; Thu, 22 Mar 2012 01:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=mB7YNDCGu1RBysG4QvWUWlZ2Ml9nruGtfo41zh7fcWk=; b=N66uHE7A9L8OU4LVtJxt8XlDYKPOQQVM0KYgIid+7La6w7eTUpswYZnjOwAIZKJcPb W/kHxcY0XG8/rQc/RSL73cqokmnvjYwlEufwBK8kIdSyQ5Z0ZfrHU7XDj3cNLLood3/e 0m2eNbdBc1ANgUS0z6cpMVBS7fL4yJ6157gRaoROVEiJ8wgeXxXk4q0O5Fr3k7dVgLh4 vagIUrd3lrG6D9UOhwUe01OcBvmmlTME2UWsshoD4G5j1pjjBJS23tPsjR7oM3F09S8i a0SvTf+hHe2nwIDoUUTrxu5myBlQqMlURQcWMW6foMXG/0NqgB8YId7nAgYMX90LL5sE 3jDw== Received: by 10.180.101.230 with SMTP id fj6mr2751379wib.13.1332404043117; Thu, 22 Mar 2012 01:14:03 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id k6sm3379805wiy.7.2012.03.22.01.14.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 01:14:02 -0700 (PDT) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> Date: Thu, 22 Mar 2012 10:12:57 +0200 Message-ID: <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031B_01CD0814.5C7F09D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8w Content-Language: en-us Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 08:14:10 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_031B_01CD0814.5C7F09D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mark, This is a good example for shorter Mutual exclusive set but taking the example from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may be different if we limit ourselves to use either representations. So if we really want to optimize the number of entries we can use Boolean equations to represent the relations. Otherwise it does not matter which method you choose and we should look at how we use this information. The important issue in not only the representation but it is how to do does the selection. In the case of simultaneous set you choose a line or part of it, very simple!!! In the case of mutually exclusive set it is not easy since you cannot just select one MC from each row (not in your example which is one case but in the example from the framework draft), you will need to combine them to Mutual exclusive sets. This is what I claimed in the previous email you sent, and why I prefer simultaneous set. I strongly object to using mutually exclusive sets unless you can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark ------=_NextPart_000_031B_01CD0814.5C7F09D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mark,

This is a good = example for shorter Mutual exclusive set but taking the example = from the framework draft

 

{VC0, VC1, = VC2, VC3, VC4, VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Will have = as exclusive set

 =

{VC0}<= /o:p>

{VC1,VC5}

{VC2}<= /o:p>

{VC3,VC5}

{VC4,VC5}

{VC6}<= /o:p>

 =

As far as = I remember my Boolean algebra the optimized number of entries may be = different if we limit ourselves to use either representations. So if we = really want to optimize the number of entries we can use Boolean = equations to represent the relations. Otherwise it does not matter which = method you choose and we should look at how we use this = information.

The = important issue in not only the representation but it  is how to do = does the selection.

 =

In the = case of simultaneous set you choose a line or part of it, very = simple!!!

 =

In the = case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but = in the example from the framework draft), you will need to combine them = to Mutual exclusive sets.

 =

This is = what I claimed in the previous email you sent, and why I prefer = simultaneous set. I strongly object to using mutually exclusive sets = unless you can explain how you can have an easy select criteria. =

The = capture sets are not providing a full picture but just a subset of the = full options that are recommended by the = provider.

 =

Roni

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 = AM
To: clue@ietf.org
Subject: [clue] Simultaneous = set, or mutually exclusive set?

 

This is a = follow on to the email thread with subject ‘propose "mutually = exclusive" attribute to replace simutaneous sets’.  It = seemed like that thread didn’t have any agreement.  So = I’ll suggest a simpler change to see what you think.  This is = motivated by a discussion at the interim meeting where I thought a few = people were in favor of this.

 

Instead of = conveying the information about which media captures can be used at the = same time with “simultaneous sets”, do it instead with = “mutually exclusive sets”.  The purpose is to have a = more concise way to indicate which media captures cannot be used at the = same time, which we believe scales better than the simultaneous set idea = when there are multiple mutually exclusive constraints.

 

Here is an = example of the difference.  Suppose a provider is advertising six = video captures.  The provider wants to say that VC1 and VC2 = can’t be used at the same time.  And VC3 and VC4 can’t = be used at the same time.  And VC5 and VC6 can’t be used at = the same time.

 

In simultaneous sets it would be expressed like = this:

{VC1, VC3, VC5}

{VC1, VC4, = VC5}

{VC1, VC3, VC6}

{VC1, VC4, = VC6}

{VC2, VC3, VC5}

{VC2, VC4, = VC5}

{VC2, VC3, VC6}

{VC2, VC4, = VC6}

 

With mutually exclusive sets, it would be expressed = like this:

{VC1, = VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody = see any advantage or disadvantage to this?

 

Mark

------=_NextPart_000_031B_01CD0814.5C7F09D0-- From espeberg@cisco.com Thu Mar 22 07:17:05 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B5F21F8582 for ; Thu, 22 Mar 2012 07:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.28 X-Spam-Level: X-Spam-Status: No, score=-10.28 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVS2ce7Ub-T1 for ; Thu, 22 Mar 2012 07:17:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B6AAE21F857F for ; Thu, 22 Mar 2012 07:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=21398; q=dns/txt; s=iport; t=1332425821; x=1333635421; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=U+cYQdQgpqZY8DEpEW3aMRDPjvrW2KN+p1vHArmRFhI=; b=QCthuoJ5qYP7v5c2rBSTmxRS0CNthNsynAEV4UFqNZoOoJSh2JXEekHc vKMn/BviP2hGSuhFf6Q+DZs1EDIdjsESQbzND4qMpWJ3VhBwsJm0FeNi3 u0KugvSgHnpE16IeReDK9fFVpftOH9LUG4Q5onMVwmwPzMtplLwzeEDSk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEsza0+Q/khL/2dsb2JhbABEgka0dIEHggkBAQEEEgEJEQNCFwIBCA4DBAEBCwYQBwEGAUUJCAEBBAESCBqHaJlPnyKKX4UiYwSkH4FogmiBVAc X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208,217";a="133069931" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2012 14:17:00 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2MEH0En021691; Thu, 22 Mar 2012 14:17:00 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 15:17:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0836.721F5716" Date: Thu, 22 Mar 2012 15:16:59 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> In-Reply-To: <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoA= References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> From: "Espen Berger (espeberg)" To: "Roni Even" , "Duckworth, Mark" , X-OriginalArrivalTime: 22 Mar 2012 14:17:00.0262 (UTC) FILETIME=[724E9060:01CD0836] Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:17:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0836.721F5716 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that mutual exclusive sets can be used to model the example 11.1 in the framework document. A snippet from the document <>=20 =20 In the example the main thing to model is that a selection of VC5 has side effects and basically exclude some of the other alternatives=20 * VC5 exclude VC1; VC1 and VC5 is the same physical camera so they cannot be sent at the same time.=20 * VC5 excludes VC3; Since the middle camera does not capture the middle segment anymore, and segment switching into middle segment is not possible anymore * VC5 excludes VC4; A composed view cannot be rendered since VC1 does not capture the middle segment anymore.=20 =20 In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax=20 =20 Cheers=20 =20 -Espen =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? =20 Hi Mark, This is a good example for shorter Mutual exclusive set but taking the example from the framework draft =20 {VC0, VC1, VC2, VC3, VC4, VC6} =20 {VC0, VC2, VC5, VC6} =20 Will have as exclusive set =20 {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} =20 As far as I remember my Boolean algebra the optimized number of entries may be different if we limit ourselves to use either representations. So if we really want to optimize the number of entries we can use Boolean equations to represent the relations. Otherwise it does not matter which method you choose and we should look at how we use this information. The important issue in not only the representation but it is how to do does the selection. =20 In the case of simultaneous set you choose a line or part of it, very simple!!! =20 In the case of mutually exclusive set it is not easy since you cannot just select one MC from each row (not in your example which is one case but in the example from the framework draft), you will need to combine them to Mutual exclusive sets.=20 =20 This is what I claimed in the previous email you sent, and why I prefer simultaneous set. I strongly object to using mutually exclusive sets unless you can explain how you can have an easy select criteria.=20 The capture sets are not providing a full picture but just a subset of the full options that are recommended by the provider. =20 Roni =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? =20 This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. =20 Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. =20 Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. =20 In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} =20 Does anybody see any advantage or disadvantage to this? =20 Mark ------_=_NextPart_001_01CD0836.721F5716 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that mutual exclusive sets can be used = to model the example 11.1 in the framework document.  A snippet = from the document <<VC5 cannot be used at the same time as VC1 or = VC3 or  VC4.>>

 

In the example the main = thing to model is that a selection of VC5 has side effects and basically = exclude some of the other alternatives

·         =  VC5 = exclude VC1; VC1 and VC5 is the same physical camera so they cannot be = sent at the same time.

·         = VC5 = excludes VC3; Since the middle camera does not capture the middle = segment anymore, and segment switching into middle segment is not = possible anymore

·         = VC5 = excludes VC4; A composed view cannot be rendered since VC1 does not = capture the middle segment anymore.

 

In other terms; = Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be = written as

{VC5, [VC1, VC3, VC4] }   // or some = other nice syntax

 

Cheers =

 

-Espen  =

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: 22. mars 2012 09:13
To: = 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] = Simultaneous set, or mutually exclusive = set?

 

Hi Mark,

This is a = good example for shorter Mutual exclusive set but taking the = example from the framework draft

 

{VC0, VC1, = VC2, VC3, VC4, VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Will have = as exclusive set

 =

{VC0}<= /o:p>

{VC1,VC5}

{VC2}<= /o:p>

{VC3,VC5}

{VC4,VC5}

{VC6}<= /o:p>

 =

As far as = I remember my Boolean algebra the optimized number of entries may be = different if we limit ourselves to use either representations. So if we = really want to optimize the number of entries we can use Boolean = equations to represent the relations. Otherwise it does not matter which = method you choose and we should look at how we use this = information.

The = important issue in not only the representation but it  is how to do = does the selection.

 =

In the = case of simultaneous set you choose a line or part of it, very = simple!!!

 =

In the = case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but = in the example from the framework draft), you will need to combine them = to Mutual exclusive sets.

 =

This is = what I claimed in the previous email you sent, and why I prefer = simultaneous set. I strongly object to using mutually exclusive sets = unless you can explain how you can have an easy select criteria. =

The = capture sets are not providing a full picture but just a subset of the = full options that are recommended by the = provider.

 =

Roni

 

 

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, = 2012 12:05 AM
To: clue@ietf.org
Subject: = [clue] Simultaneous set, or mutually exclusive = set?

 

This is a follow on to the email thread with subject = ‘propose "mutually exclusive" attribute to replace = simutaneous sets’.  It seemed like that thread didn’t = have any agreement.  So I’ll suggest a simpler change to see = what you think.  This is motivated by a discussion at the interim = meeting where I thought a few people were in favor of = this.

 

Instead of conveying the information about which media = captures can be used at the same time with “simultaneous = sets”, do it instead with “mutually exclusive = sets”.  The purpose is to have a more concise way to indicate = which media captures cannot be used at the same time, which we believe = scales better than the simultaneous set idea when there are multiple = mutually exclusive constraints.

 

Here is an example of the = difference.  Suppose a provider is advertising six video = captures.  The provider wants to say that VC1 and VC2 can’t = be used at the same time.  And VC3 and VC4 can’t be used at = the same time.  And VC5 and VC6 can’t be used at the same = time.

 

In simultaneous sets it would be = expressed like this:

{VC1, VC3, = VC5}

{VC1, VC4, VC5}

{VC1, VC3, = VC6}

{VC1, VC4, VC6}

{VC2, VC3, = VC5}

{VC2, VC4, VC5}

{VC2, VC3, = VC6}

{VC2, VC4, VC6}

 

With mutually exclusive sets, it = would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage or = disadvantage to this?

 

Mark

------_=_NextPart_001_01CD0836.721F5716-- From Mark.Duckworth@polycom.com Thu Mar 22 07:42:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0CD21F8517 for ; Thu, 22 Mar 2012 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND4vvHEWen00 for ; Thu, 22 Mar 2012 07:42:26 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 17E0721F8589 for ; Thu, 22 Mar 2012 07:42:26 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 22 Mar 2012 07:42:25 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 22 Mar 2012 07:42:22 -0700 Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAO7pcA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A12@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A12CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:42:29 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A12CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is simple to represent this using the mutually exclusive idea, with no m= ore complicated syntax: {VC1,VC5} {VC3,VC5} {VC4,VC5} Meaning that VC5 cannot be used simultaneously with any of VC1, VC3, or VC4= . Roni wrote: "In the case of simultaneous set you choose a line or part of i= t, very simple!!!" That is true, but also (and usually even simpler IMHO) the consumer can cho= ose a capture scene entry or part of it. If the consumer chooses from capt= ure scene entries, then it doesn't even have to look at the simultaneous (o= r mutually exclusive) sets. Mark From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 10:17 AM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives * VC5 exclude VC1; VC1 and VC5 is the same physical camera so they= cannot be sent at the same time. * VC5 excludes VC3; Since the middle camera does not capture the mi= ddle segment anymore, and segment switching into middle segment is not poss= ible anymore * VC5 excludes VC4; A composed view cannot be rendered since VC1 do= es not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject 'propose "mutually exc= lusive" attribute to replace simutaneous sets'. It seemed like that thread= didn't have any agreement. So I'll suggest a simpler change to see what y= ou think. This is motivated by a discussion at the interim meeting where I= thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with "simultaneous sets", do it instead with "mutually ex= clusive sets". The purpose is to have a more concise way to indicate which= media captures cannot be used at the same time, which we believe scales be= tter than the simultaneous set idea when there are multiple mutually exclus= ive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can't be used= at the same time. And VC3 and VC4 can't be used at the same time. And VC= 5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A12CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is simple to represent this using the mutually exclusive i= dea, with no more complicated syntax:

{VC1,VC5}

{VC3,VC5}

<= p class=3DMsoNormal>{VC4,VC5}

Meaning that VC5 c= annot be used simultaneously with any of VC1, VC3, or VC4.

 

Roni wrote: “In the case of simultaneous set y= ou choose a line or part of it, very simple!!!”

That is true, but also (and= usually even simpler IMHO) the consumer can choose a capture scene entry o= r part of it.  If the consumer chooses from capture scene entries, the= n it doesn’t even have to look at the simultaneous (or mutually exclu= sive) sets.

 

Mark

 

From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Se= nt: Thursday, March 22, 2012 10:17 AM
To: Roni Even; Duckwort= h, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or m= utually exclusive set?

 

I think that mutual exclusive sets can be used to model the exa= mple 11.1 in the framework document.  A snippet from the document <= <VC5 cannot be used at the same time as VC1 or VC3 or  VC4.>>=

 

In the example the main thing to model is that= a selection of VC5 has side effects and basically exclude some of the othe= r alternatives

·  &= nbsp;       VC5 exclude VC1; VC1 and VC5 is th= e same physical camera so they cannot be sent at the same time. =

·      &nbs= p;  VC5 excludes VC3; Since the middle camera does not capture the midd= le segment anymore, and segment switching into middle segment is not possib= le anymore

·   &= nbsp;     VC5 excludes VC4; A composed view cannot be re= ndered since VC1 does not capture the middle segment anymore.

 

In other terms; Selecting VC5 excludes usage of capture VC1,= VC3, VC4 which could be written as

{VC5, [VC1, VC3, VC4] }  = ; // or some other nice syntax

 

=

Cheers

 

-Espen 

 

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Roni Even
Sent: 22. mars 20= 12 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: = Re: [clue] Simultaneous set, or mutually exclusive set?

 

Hi Mark,

This is a g= ood example for shorter Mutual exclusive set but taking the example = from the framework draft

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>{VC0, VC= 1, VC2, VC3, VC4, VC6}

 

      {VC0, VC2, VC= 5, VC6}

 

<= p class=3DMsoPlainText>Will have as exclusive set

 

{VC0}<= /p>

{VC1,VC5}

= {VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}<= /span>

 

As = far as I remember my Boolean algebra the optimized number of entries may be= different if we limit ourselves to use either representations. So if we re= ally want to optimize the number of entries we can use Boolean equations to= represent the relations. Otherwise it does not matter which method you cho= ose and we should look at how we use this information.

The important issue in not only the representation but it=  is how to do does the selection.

 

In the case of simultaneous= set you choose a line or part of it, very simple!!!

<= p class=3DMsoPlainText> 

In the case of= mutually exclusive set it is not easy since you cannot just select one MC = from each row (not in your example which is one case but in the example fro= m the framework draft), you will need to combine them to Mutual exclusive s= ets.

 

This is what I claimed in the previous email you sent, and wh= y I prefer simultaneous set. I strongly object to using mutually exclusive = sets unless you can explain how you can have an easy select criteria. =

The capture sets are not providing a full= picture but just a subset of the full options that are recommended by the = provider.

 

Roni

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
<= b>Sent: Tuesday, March 20, 2012 12:05 AM
To: clue@ietf.org
Subject: [clue] Simultaneous s= et, or mutually exclusive set?

 

This is a follow on to = the email thread with subject ‘propose "mutually exclusive"= attribute to replace simutaneous sets’.  It seemed like that th= read didn’t have any agreement.  So I’ll suggest a simpler= change to see what you think.  This is motivated by a discussion at t= he interim meeting where I thought a few people were in favor of this.=

 

In= stead of conveying the information about which media captures can be used a= t the same time with “simultaneous sets”, do it instead with &#= 8220;mutually exclusive sets”.  The purpose is to have a more co= ncise way to indicate which media captures cannot be used at the same time,= which we believe scales better than the simultaneous set idea when there a= re multiple mutually exclusive constraints.

 

Here is an example of the dif= ference.  Suppose a provider is advertising six video captures.  = The provider wants to say that VC1 and VC2 can’t be used at the same = time.  And VC3 and VC4 can’t be used at the same time.  And= VC5 and VC6 can’t be used at the same time.

 

In simultaneous sets it would be expressed like this:<= /span>

{VC1, VC3, VC5= }

{= VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

=

{VC2, VC4, VC5}

{VC2, VC3, = VC6}

{VC2, VC4, VC6}

 

With mutually exclusive sets, it would be expres= sed like this:

{VC1, VC2}

=

{VC3, VC4}

{VC5, VC= 6}

 

Does anybody see any advantage or disadvantage to this?

=

 

Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A12CRPMBOXPRD01p_-- From ron.even.tlv@gmail.com Thu Mar 22 08:09:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1503921F861D for ; Thu, 22 Mar 2012 08:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YoGBreyeLbmR for ; Thu, 22 Mar 2012 08:09:26 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7A64D21F8604 for ; Thu, 22 Mar 2012 08:09:25 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so992376wgb.13 for ; Thu, 22 Mar 2012 08:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=ZWPlJD5Ss9A5qmVuRS/fIuxe2O+znPlX3zZWoiCt11s=; b=u32x60x3F1iKNxGiDX23XFdELgZZJkgP6++BO8HzEBZNqENHhNGvhBYGxuW+1ezoEd OddcwWCdLFETjjxKQORqoWIgayxzGZci2r09157BpC6k1KgDYMtQAGuL1Zs5/a2dMt6E mxru6zFzf/BMmzSPlo3CyGnnSa9Bus3A6+BbXtVRAaxjW1GfUhsn8clWeFYQI2cy+Nnq NMORneA5jqFlMaR6sXO2IXGiVU1mzMzXMRanKQO3zTtpuZPwXESHwmUWwY+K7shPtpZn sldasgzDoBP/JXto2tvMxL0Yi1hT9defqvbqw8pWB/nHaLXKjAPiC8ky4egQm6jtaJ4j fw6g== Received: by 10.180.98.8 with SMTP id ee8mr6075507wib.14.1332428964621; Thu, 22 Mar 2012 08:09:24 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-219-130.red.bezeqint.net. [79.179.219.130]) by mx.google.com with ESMTPS id gp8sm5870477wib.5.2012.03.22.08.09.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 08:09:23 -0700 (PDT) From: "Roni Even" To: "'Espen Berger \(espeberg\)'" , "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> Date: Thu, 22 Mar 2012 17:08:18 +0200 Message-ID: <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0357_01CD084E.6258A3E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AA== Content-Language: en-us Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:09:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0357_01CD084E.6258A3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Espen, This is different since now you have a combination of simultaneous set and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to be more in line with Boolean algebra in which case we will need to define the syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side effects and basically exclude some of the other alternatives . VC5 exclude VC1; VC1 and VC5 is the same physical camera so they cannot be sent at the same time. . VC5 excludes VC3; Since the middle camera does not capture the middle segment anymore, and segment switching into middle segment is not possible anymore . VC5 excludes VC4; A composed view cannot be rendered since VC1 does not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the example from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may be different if we limit ourselves to use either representations. So if we really want to optimize the number of entries we can use Boolean equations to represent the relations. Otherwise it does not matter which method you choose and we should look at how we use this information. The important issue in not only the representation but it is how to do does the selection. In the case of simultaneous set you choose a line or part of it, very simple!!! In the case of mutually exclusive set it is not easy since you cannot just select one MC from each row (not in your example which is one case but in the example from the framework draft), you will need to combine them to Mutual exclusive sets. This is what I claimed in the previous email you sent, and why I prefer simultaneous set. I strongly object to using mutually exclusive sets unless you can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark ------=_NextPart_000_0357_01CD084E.6258A3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Espen,

This is different since now = you have a combination  of simultaneous set  and mutual = exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} =   

This is not what = Mark was proposing and this expands the representation to be more in = line with Boolean algebra in which case we will need to define the = syntax for (AND, OR, XOR,..)

This = will allow having Mark example as

{VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR = VC6}

 

The selection becomes one from each OR and all or some = of the AND.

 

Do we want to go to this syntax?

 

 

Roni

 

 

From:= = Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: = Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, = Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or = mutually exclusive set?

 

I think that mutual exclusive sets = can be used to model the example 11.1 in the framework document.  A = snippet from the document <<VC5 cannot be used at the same time as = VC1 or VC3 or  VC4.>>

 

In the = example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives =

·         =  VC5 exclude VC1; VC1 and VC5 is the same = physical camera so they cannot be sent at the same time. =

·         = VC5 excludes VC3; Since the middle camera does = not capture the middle segment anymore, and segment switching into = middle segment is not possible anymore

·         = VC5 excludes VC4; A composed view cannot be = rendered since VC1 does not capture the middle segment anymore. =

 

In other = terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could = be written as

{VC5, [VC1, VC3, VC4] } =   // or some other nice syntax

 

Cheers =

 

-Espen 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Roni Even
Sent: 22. mars 2012 = 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: = [clue] Simultaneous set, or mutually exclusive = set?

 

Hi Mark,

This is a good = example for shorter Mutual exclusive set but taking the example = from the framework draft

 

{VC0, VC1, = VC2, VC3, VC4, VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Will have = as exclusive set

 =

{VC0}<= /o:p>

{VC1,VC5}

{VC2}<= /o:p>

{VC3,VC5}

{VC4,VC5}

{VC6}<= /o:p>

 =

As far as = I remember my Boolean algebra the optimized number of entries may be = different if we limit ourselves to use either representations. So if we = really want to optimize the number of entries we can use Boolean = equations to represent the relations. Otherwise it does not matter which = method you choose and we should look at how we use this = information.

The = important issue in not only the representation but it  is how to do = does the selection.

 =

In the = case of simultaneous set you choose a line or part of it, very = simple!!!

 =

In the = case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but = in the example from the framework draft), you will need to combine them = to Mutual exclusive sets.

 =

This is = what I claimed in the previous email you sent, and why I prefer = simultaneous set. I strongly object to using mutually exclusive sets = unless you can explain how you can have an easy select criteria. =

The = capture sets are not providing a full picture but just a subset of the = full options that are recommended by the = provider.

 =

Roni

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, = 2012 12:05 AM
To: clue@ietf.org
Subject: = [clue] Simultaneous set, or mutually exclusive = set?

 

This is a = follow on to the email thread with subject ‘propose "mutually = exclusive" attribute to replace simutaneous sets’.  It = seemed like that thread didn’t have any agreement.  So = I’ll suggest a simpler change to see what you think.  This is = motivated by a discussion at the interim meeting where I thought a few = people were in favor of this.

 

Instead of = conveying the information about which media captures can be used at the = same time with “simultaneous sets”, do it instead with = “mutually exclusive sets”.  The purpose is to have a = more concise way to indicate which media captures cannot be used at the = same time, which we believe scales better than the simultaneous set idea = when there are multiple mutually exclusive constraints.

 

Here is an = example of the difference.  Suppose a provider is advertising six = video captures.  The provider wants to say that VC1 and VC2 = can’t be used at the same time.  And VC3 and VC4 can’t = be used at the same time.  And VC5 and VC6 can’t be used at = the same time.

 

In simultaneous sets it would be expressed like = this:

{VC1, VC3, VC5}

{VC1, VC4, = VC5}

{VC1, VC3, VC6}

{VC1, VC4, = VC6}

{VC2, VC3, VC5}

{VC2, VC4, = VC5}

{VC2, VC3, VC6}

{VC2, VC4, = VC6}

 

With mutually exclusive sets, it would be expressed = like this:

{VC1, = VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody = see any advantage or disadvantage to this?

 

Mark

------=_NextPart_000_0357_01CD084E.6258A3E0-- From Mark.Duckworth@polycom.com Thu Mar 22 08:18:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A86621F84F6 for ; Thu, 22 Mar 2012 08:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRinRPXobOuG for ; Thu, 22 Mar 2012 08:18:45 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1354621F849B for ; Thu, 22 Mar 2012 08:18:44 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 22 Mar 2012 08:18:44 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 22 Mar 2012 08:18:40 -0700 Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6g Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> In-Reply-To: <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:18:48 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives * VC5 exclude VC1; VC1 and VC5 is the same physical camera so they= cannot be sent at the same time. * VC5 excludes VC3; Since the middle camera does not capture the mi= ddle segment anymore, and segment switching into middle segment is not poss= ible anymore * VC5 excludes VC4; A composed view cannot be rendered since VC1 do= es not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject 'propose "mutually exc= lusive" attribute to replace simutaneous sets'. It seemed like that thread= didn't have any agreement. So I'll suggest a simpler change to see what y= ou think. This is motivated by a discussion at the interim meeting where I= thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with "simultaneous sets", do it instead with "mutually ex= clusive sets". The purpose is to have a more concise way to indicate which= media captures cannot be used at the same time, which we believe scales be= tter than the simultaneous set idea when there are multiple mutually exclus= ive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can't be used= at the same time. And VC3 and VC4 can't be used at the same time. And VC= 5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would rather not complicate this with Boolean algebra.=

Mark

=  

From: Roni E= ven [mailto:ron.even.tlv@gmail.com]
Sent: Thursday, March 22, 20= 12 11:08 AM
To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@= ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclus= ive set?

 <= /o:p>

Hi Espen,

= This is different since now you have a combination  of simultaneous se= t  and mutual exclusive. Like {VC5 OR (VC1 AND VC3 = AND VC4)}   

This is no= t what Mark was proposing and this expands the representation to be more in= line with Boolean algebra in which case we will need to define the syntax = for (AND, OR, XOR,..)

This will allow ha= ving Mark example as

{VC1 OR VC2} AND {= VC3 OR VC4} AND {VC5 OR VC6}

 =

The selection becomes one from each OR and a= ll or some of the AND.

 =

Do we want to go to this syntax?

 

 

Roni

&nb= sp;

 =

From: Espen Berg= er (espeberg) [mailto:espeberg@cisco.com]
Sent: Thursday, March = 22, 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.orgSubject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

I think that = mutual exclusive sets can be used to model the example 11.1 in the framewor= k document.  A snippet from the document <<VC5 cannot be used at= the same time as VC1 or VC3 or  VC4.>>

 

In the example the main thing to model is that a selection of VC5 has s= ide effects and basically exclude some of the other alternatives

·      &nb= sp;   VC5 exclude VC1; VC1 and VC5 is the same physical camera so = they cannot be sent at the same time.

<= span style=3D'mso-list:Ignore'>·         VC5 excludes VC3; = Since the middle camera does not capture the middle segment anymore, and se= gment switching into middle segment is not possible anymore

·       &nb= sp; VC5 excludes VC4; A composed view cannot be rendered since VC1 does not = capture the middle segment anymore.

 

=

In other te= rms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be w= ritten as

{VC5, [VC1, VC3, VC4] }   // or some other ni= ce syntax

 

Cheers

 

-E= spen 

 

From: clue-bounces@ietf.or= g [mailto:clue-bounces@ietf.or= g] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13To: 'Duckworth, Mark'; clue@ietf.o= rg
Subject: Re: [clue] Simultaneous set, or mutually exclusiv= e set?

 

Hi Mark,

This is a good example for shorter Mutual exclusive s= et but taking the example from the framework draft

 

{VC0, VC1, VC2, VC3, VC4, VC6}

 

   =    {VC0, VC2, VC5, VC6}

 

Will have as exclusive set

 

{VC0}

{VC1,VC5}

{VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}

 

As far as I remember my Boolean algebra the optimize= d number of entries may be different if we limit ourselves to use either re= presentations. So if we really want to optimize the number of entries we ca= n use Boolean equations to represent the relations. Otherwise it does not m= atter which method you choose and we should look at how we use this informa= tion.

The important issue in not only= the representation but it  is how to do does the selection.

 

I= n the case of simultaneous set you choose a line or part of it, very simple= !!!

 

In the case of mutually exclusive set it is not easy since you = cannot just select one MC from each row (not in your example which is one c= ase but in the example from the framework draft), you will need to combine = them to Mutual exclusive sets.

=  

This is what I claimed in the previ= ous email you sent, and why I prefer simultaneous set. I strongly object to= using mutually exclusive sets unless you can explain how you can have an e= asy select criteria.

The capture set= s are not providing a full picture but just a subset of the full options th= at are recommended by the provider.

<= o:p> 

Roni

 

 = ;

&= nbsp;

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf O= f Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM
<= b>To: clue@ietf.org
Subject:= [clue] Simultaneous set, or mutually exclusive set?<= /p>

 

This is a follow on to the email thread with subject ‘propose &quo= t;mutually exclusive" attribute to replace simutaneous sets’.&nb= sp; It seemed like that thread didn’t have any agreement.  So I&= #8217;ll suggest a simpler change to see what you think.  This is moti= vated by a discussion at the interim meeting where I thought a few people w= ere in favor of this.

 <= /p>

Instead of conveying the information about which me= dia captures can be used at the same time with “simultaneous setsR= 21;, do it instead with “mutually exclusive sets”.  The pu= rpose is to have a more concise way to indicate which media captures cannot= be used at the same time, which we believe scales better than the simultan= eous set idea when there are multiple mutually exclusive constraints.<= /o:p>

 

Her= e is an example of the difference.  Suppose a provider is advertising = six video captures.  The provider wants to say that VC1 and VC2 can= 217;t be used at the same time.  And VC3 and VC4 can’t be used a= t the same time.  And VC5 and VC6 can’t be used at the same time= .

 

In simultaneous sets it would be expresse= d like this:

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}=

{VC2, VC3, VC= 5}

= {VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

 

With mutually exclusive = sets, it would be expressed like this:

{= VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage or disadvantage= to this?

 

Mark

= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38CRPMBOXPRD01p_-- From espeberg@cisco.com Thu Mar 22 09:20:47 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B816021F8653 for ; Thu, 22 Mar 2012 09:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of2nvAYZ7U3r for ; Thu, 22 Mar 2012 09:20:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 59E4B21F8622 for ; Thu, 22 Mar 2012 09:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=29621; q=dns/txt; s=iport; t=1332433242; x=1333642842; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=OQtWpDGxMz4F/9beuT94UX70khxbkgXtVjCvGcfBh8c=; b=fzeNv8k5PuaUv2Ta+RHxx1zR5FlG5l6fTXdxS18whXpH+TLC62kQCzt7 SMqmehewABeSi5yhKLRXjgn61erOMVCSsXwqb50bj2qb0lIzoEP26F5Ee MR/jvu62pl93O8NGYQ3HEaSPerVs1TwUyCwVfGzemh07i8mANtiU9taMj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANNQa0+Q/khL/2dsb2JhbABEgka0doEHggkBAQEEEgEJEQNCFwIBCBEEAQELBhABBgEGASAlCQgBAQQBEggah2iZV58oiW1yhSJjBKEOgxGBaIJogVQH X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208,217";a="133087338" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2012 16:20:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2MGKeVI019801; Thu, 22 Mar 2012 16:20:40 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 17:20:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0847.B9321DD2" Date: Thu, 22 Mar 2012 17:20:39 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFA= References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com><4f6adf4a.c652b40a.5727.ffff935d@mx.google.com><92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com><4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> From: "Espen Berger (espeberg)" To: "Duckworth, Mark" , X-OriginalArrivalTime: 22 Mar 2012 16:20:40.0796 (UTC) FILETIME=[B94A31C0:01CD0847] Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 16:20:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0847.B9321DD2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No Boolean algebra is needed. I do not think we need that complexity in what we want to describe.=20 =20 I agree with marks suggestion to write it up like this:=20 {VC1,VC5} {VC3,VC5} {VC4,VC5} =20 Cheers=20 =20 -Espen=20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? =20 I would rather not complicate this with Boolean algebra. Mark =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? =20 Hi Espen, This is different since now you have a combination of simultaneous set and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} =20 This is not what Mark was proposing and this expands the representation to be more in line with Boolean algebra in which case we will need to define the syntax for (AND, OR, XOR,..) This will allow having Mark example as=20 {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} =20 The selection becomes one from each OR and all or some of the AND. =20 Do we want to go to this syntax? =20 =20 Roni =20 =20 From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]=20 Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? =20 I think that mutual exclusive sets can be used to model the example 11.1 in the framework document. A snippet from the document <>=20 =20 In the example the main thing to model is that a selection of VC5 has side effects and basically exclude some of the other alternatives=20 * VC5 exclude VC1; VC1 and VC5 is the same physical camera so they cannot be sent at the same time.=20 * VC5 excludes VC3; Since the middle camera does not capture the middle segment anymore, and segment switching into middle segment is not possible anymore * VC5 excludes VC4; A composed view cannot be rendered since VC1 does not capture the middle segment anymore.=20 =20 In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax=20 =20 Cheers=20 =20 -Espen =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? =20 Hi Mark, This is a good example for shorter Mutual exclusive set but taking the example from the framework draft =20 {VC0, VC1, VC2, VC3, VC4, VC6} =20 {VC0, VC2, VC5, VC6} =20 Will have as exclusive set =20 {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} =20 As far as I remember my Boolean algebra the optimized number of entries may be different if we limit ourselves to use either representations. So if we really want to optimize the number of entries we can use Boolean equations to represent the relations. Otherwise it does not matter which method you choose and we should look at how we use this information. The important issue in not only the representation but it is how to do does the selection. =20 In the case of simultaneous set you choose a line or part of it, very simple!!! =20 In the case of mutually exclusive set it is not easy since you cannot just select one MC from each row (not in your example which is one case but in the example from the framework draft), you will need to combine them to Mutual exclusive sets.=20 =20 This is what I claimed in the previous email you sent, and why I prefer simultaneous set. I strongly object to using mutually exclusive sets unless you can explain how you can have an easy select criteria.=20 The capture sets are not providing a full picture but just a subset of the full options that are recommended by the provider. =20 Roni =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? =20 This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. =20 Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. =20 Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. =20 In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} =20 Does anybody see any advantage or disadvantage to this? =20 Mark ------_=_NextPart_001_01CD0847.B9321DD2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No Boolean algebra is needed. I do not think we = need that complexity in what we want to describe. =

 

I agree with marks = suggestion to write it up like this:

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}

 

Cheers =

 

-Espen =

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: 22. mars 2012 16:19
To: = clue@ietf.org
Subject: Re: [clue] Simultaneous set, or = mutually exclusive set?

 

I would rather not complicate this = with Boolean algebra.

Mark

 

From:= Roni Even = [mailto:ron.even.tlv@gmail.com]=
Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen = Berger (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] Simultaneous set, or mutually exclusive = set?

 

Hi Espen,

This is different since now you have a combination  of = simultaneous set  and mutual exclusive. Like {VC5 OR (VC1 = AND VC3 AND VC4)}   

This is not what Mark was proposing and this expands the = representation to be more in line with Boolean algebra in which case we = will need to define the syntax for (AND, OR, = XOR,..)

This will allow having Mark example as =

{VC1 OR = VC2} AND {VC3 OR VC4} AND {VC5 OR VC6}

 

The selection becomes one from each = OR and all or some of the AND.

 

Do we want to go to this = syntax?

 

 

Roni

 

 

From:= Espen = Berger (espeberg) [mailto:espeberg@cisco.com] =
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni = Even; Duckworth, Mark; clue@ietf.org
Subject: RE: = [clue] Simultaneous set, or mutually exclusive = set?

 

I think that mutual exclusive sets can be used = to model the example 11.1 in the framework document.  A snippet = from the document <<VC5 cannot be used at the same time as VC1 or = VC3 or  VC4.>>

 

In the example the main = thing to model is that a selection of VC5 has side effects and basically = exclude some of the other alternatives

·         =  VC5 = exclude VC1; VC1 and VC5 is the same physical camera so they cannot be = sent at the same time.

·         = VC5 = excludes VC3; Since the middle camera does not capture the middle = segment anymore, and segment switching into middle segment is not = possible anymore

·         = VC5 = excludes VC4; A composed view cannot be rendered since VC1 does not = capture the middle segment anymore.

 

In other terms; = Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be = written as

{VC5, [VC1, VC3, VC4] }   // or some = other nice syntax

 

Cheers =

 

-Espen  =

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Roni Even
Sent: 22. mars 2012 = 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: = [clue] Simultaneous set, or mutually exclusive = set?

 

Hi Mark,

This is a = good example for shorter Mutual exclusive set but taking the = example from the framework draft

 

{VC0, VC1, = VC2, VC3, VC4, VC6}

 =

  = ;    {VC0, VC2, VC5, VC6}

 =

Will have = as exclusive set

 =

{VC0}<= /o:p>

{VC1,VC5}

{VC2}<= /o:p>

{VC3,VC5}

{VC4,VC5}

{VC6}<= /o:p>

 =

As far as = I remember my Boolean algebra the optimized number of entries may be = different if we limit ourselves to use either representations. So if we = really want to optimize the number of entries we can use Boolean = equations to represent the relations. Otherwise it does not matter which = method you choose and we should look at how we use this = information.

The = important issue in not only the representation but it  is how to do = does the selection.

 =

In the = case of simultaneous set you choose a line or part of it, very = simple!!!

 =

In the = case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but = in the example from the framework draft), you will need to combine them = to Mutual exclusive sets.

 =

This is = what I claimed in the previous email you sent, and why I prefer = simultaneous set. I strongly object to using mutually exclusive sets = unless you can explain how you can have an easy select criteria. =

The = capture sets are not providing a full picture but just a subset of the = full options that are recommended by the = provider.

 =

Roni

 

 

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, = 2012 12:05 AM
To: clue@ietf.org
Subject: = [clue] Simultaneous set, or mutually exclusive = set?

 

This is a follow on to the email thread with subject = ‘propose "mutually exclusive" attribute to replace = simutaneous sets’.  It seemed like that thread didn’t = have any agreement.  So I’ll suggest a simpler change to see = what you think.  This is motivated by a discussion at the interim = meeting where I thought a few people were in favor of = this.

 

Instead of conveying the information about which media = captures can be used at the same time with “simultaneous = sets”, do it instead with “mutually exclusive = sets”.  The purpose is to have a more concise way to indicate = which media captures cannot be used at the same time, which we believe = scales better than the simultaneous set idea when there are multiple = mutually exclusive constraints.

 

Here is an example of the = difference.  Suppose a provider is advertising six video = captures.  The provider wants to say that VC1 and VC2 can’t = be used at the same time.  And VC3 and VC4 can’t be used at = the same time.  And VC5 and VC6 can’t be used at the same = time.

 

In simultaneous sets it would be = expressed like this:

{VC1, VC3, = VC5}

{VC1, VC4, VC5}

{VC1, VC3, = VC6}

{VC1, VC4, VC6}

{VC2, VC3, = VC5}

{VC2, VC4, VC5}

{VC2, VC3, = VC6}

{VC2, VC4, VC6}

 

With mutually exclusive sets, it = would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage or = disadvantage to this?

 

Mark

------_=_NextPart_001_01CD0847.B9321DD2-- From Even.roni@huawei.com Thu Mar 22 13:00:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907CC21F8543 for ; Thu, 22 Mar 2012 13:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZiLv9DWnZiy for ; Thu, 22 Mar 2012 13:00:34 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9FC21F8542 for ; Thu, 22 Mar 2012 13:00:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP69350; Thu, 22 Mar 2012 16:00:33 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 12:58:51 -0700 Received: from SZXEML436-HUB.china.huawei.com (10.72.61.64) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 12:58:49 -0700 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.202]) by szxeml436-hub.china.huawei.com ([10.72.61.64]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 03:58:43 +0800 From: Roni even To: "Espen Berger (espeberg)" , "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlw== Date: Thu, 22 Mar 2012 19:58:42 +0000 Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com><4f6adf4a.c652b40a.5727.ffff935d@mx.google.com><92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com><4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com>, <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: multipart/alternative; boundary="_000_EADCEEE0AE4A7F46BD61061696794D9819E4925Eszxeml536mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 20:00:35 -0000 --_000_EADCEEE0AE4A7F46BD61061696794D9819E4925Eszxeml536mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Espen, I am confused now since for the example from the framework you suggested a = mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones i= n the [] are simultaneous while the one in {} are mutual exclusive. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Espen Berg= er (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in wha= t we want to describe. I agree with marks suggestion to write it up like this: {VC1,VC5} {VC3,VC5} {VC4,VC5} Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives =95 VC5 exclude VC1; VC1 and VC5 is the same physical camera so th= ey cannot be sent at the same time. =95 VC5 excludes VC3; Since the middle camera does not capture the = middle segment anymore, and segment switching into middle segment is not po= ssible anymore =95 VC5 excludes VC4; A composed view cannot be rendered since VC1 = does not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject =91propose "mutually e= xclusive" attribute to replace simutaneous sets=92. It seemed like that th= read didn=92t have any agreement. So I=92ll suggest a simpler change to se= e what you think. This is motivated by a discussion at the interim meeting= where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with =93simultaneous sets=94, do it instead with =93mutua= lly exclusive sets=94. The purpose is to have a more concise way to indica= te which media captures cannot be used at the same time, which we believe s= cales better than the simultaneous set idea when there are multiple mutuall= y exclusive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can=92t be us= ed at the same time. And VC3 and VC4 can=92t be used at the same time. An= d VC5 and VC6 can=92t be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_EADCEEE0AE4A7F46BD61061696794D9819E4925Eszxeml536mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Espen,

I am confused now since for the example from the framework you suggested= a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] a= re simultaneous while the one in {} are mutual exclusive.

 

Roni

From: clue-bounces@ietf.org [clue-bounces@= ietf.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com]
Sent: Thursday, March 22, 2012 18:20
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

No Boolean algebra is= needed. I do not think we need that complexity in what we want to describe= .

 

I agree with marks su= ggestion to write it up like this:

{VC1,V= C5}

{VC3,V= C5}

{VC4,V= C5}

 

Cheers

 

-Espen

 

 

From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 22. mars 2012 16:19
To: clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

 

I woul= d rather not complicate this with Boolean algebra.

Mark

 

From: Roni Even [mailto:ron.even.tlv@= gmail.com]
Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Hi Espen,

This is different since now you= have a combination  of simultaneous set  and mutual exclusive. L= ike {VC5 OR (VC1 AND VC3 AND VC4)}   

This is not what Mark was propo= sing and this expands the representation to be more in line with Boolean al= gebra in which case we will need to define the syntax for (AND, OR, XOR,..)=

This will allow having Mark exa= mple as

{VC1 OR VC2} AND {VC3 OR VC4} A= ND {VC5 OR VC6}

 

The selection becomes one from = each OR and all or some of the AND.

 

Do we want to go to this syntax= ?

 

 

Roni

 

 

From: Espen Berger (es= peberg) [mailto:esp= eberg@cisco.com]
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

I think that mutual e= xclusive sets can be used to model the example 11.1 in the framework docume= nt.  A snippet from the document <<VC5 cannot be used at the sam= e time as VC1 or VC3 or  VC4.>>

 

In the example the ma= in thing to model is that a selection of VC5 has side effects and basically= exclude some of the other alternatives

=B7          VC5 exclude VC1; = VC1 and VC5 is the same physical camera so they cannot be sent at the same = time.

=B7         VC5 excludes VC3; Since= the middle camera does not capture the middle segment anymore, and segment= switching into middle segment is not possible anymore

=B7         VC5 excludes VC4; A com= posed view cannot be rendered since VC1 does not capture the middle segment= anymore.

 

In other terms; Selec= ting VC5 excludes usage of capture VC1, VC3, VC4 which could be written as<= /span>

{VC5, [VC1, VC3, VC4]= }   // or some other nice syntax

 

Cheers

 

-Espen  <= /p>

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

 

Hi Mar= k,

This i= s a good example for shorter Mutual exclusive set but taking the example from th= e framework draft

 

 

 

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM
To: clue@ietf.org=
Subject: [clue] Simultaneous set, or mutually exclusive set?<= /p>

 

This is a follow on to the emai= l thread with subject =91propose "mutually exclusive" attribute t= o replace simutaneous sets=92.  It seemed like that thread didn=92t ha= ve any agreement.  So I=92ll suggest a simpler change to see what you think.  This is motivated by a discussion at the interim mee= ting where I thought a few people were in favor of this.

 

Instead of conveying the inform= ation about which media captures can be used at the same time with =93simul= taneous sets=94, do it instead with =93mutually exclusive sets=94.  Th= e purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe sca= les better than the simultaneous set idea when there are multiple mutually = exclusive constraints.

 

Here is an example of the diffe= rence.  Suppose a provider is advertising six video captures.  Th= e provider wants to say that VC1 and VC2 can=92t be used at the same time.&= nbsp; And VC3 and VC4 can=92t be used at the same time.  And VC5 and VC6 can=92t be used at the same time.

 

In sim= ultaneous sets it would be expressed like this:

{VC1, = VC3, VC5}

{VC1, = VC4, VC5}

{VC1, = VC3, VC6}

{VC1, = VC4, VC6}

{VC2, = VC3, VC5}

{VC2, = VC4, VC5}

{VC2, = VC3, VC6}

{VC2, = VC4, VC6}

 

With mutually exclusive sets, i= t would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage = or disadvantage to this?

 

Mark

--_000_EADCEEE0AE4A7F46BD61061696794D9819E4925Eszxeml536mbxchi_-- From espeberg@cisco.com Thu Mar 22 13:34:46 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDD421F84EE for ; Thu, 22 Mar 2012 13:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MitzNJ6H-zFy for ; Thu, 22 Mar 2012 13:34:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCBD21F84DD for ; Thu, 22 Mar 2012 13:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=36505; q=dns/txt; s=iport; t=1332448481; x=1333658081; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=uUijAZ/HIkZxL6VKiJqtz1N3iMXu0n/2TSUJvSZVPtM=; b=Elr31T90RcLh2emXmMxl0xLRuNsdskvutEygOKxDX/QHGqbAQxgx5lTY 53/abCsQiisesiD8BOgyZmAKaHelt7wNNVE9+I8V3CfbD42n1Hd7xJske bZ311+j9znRmnUGjXJT5BaR0b7rd3uDTfVgtWPUBaFqtfNEVfgc/gHC6P w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHOLa0+Q/khN/2dsb2JhbABEgka0d4EHggkBAQEEEgEJEQNCFwIBCBEEAQELBhABBgEGASAlCQgCBAESCBqHaJkonxGJbXKFImMEoQ6DEYFogmiBVAc X-IronPort-AV: E=Sophos;i="4.73,632,1325462400"; d="scan'208,217";a="133110542" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 22 Mar 2012 20:34:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2MKYdq7014786; Thu, 22 Mar 2012 20:34:39 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 21:34:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD086B.344BA86E" Date: Thu, 22 Mar 2012 21:29:42 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlwAAWQ5Q References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> From: "Espen Berger (espeberg)" To: "Roni even" , "Duckworth, Mark" , X-OriginalArrivalTime: 22 Mar 2012 20:34:39.0702 (UTC) FILETIME=[3462B760:01CD086B] Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 20:34:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD086B.344BA86E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roni, in my example I only ment to express that VC5 cannot be sent at the same time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. =20 =20 So Marks suggested notation is compact, easy to understand and cover the example from the framework.=20 =20 -Espen=20 =20 =20 From: Roni even [mailto:Even.roni@huawei.com]=20 Sent: 22. mars 2012 20:59 To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? =20 Espen, I am confused now since for the example from the framework you suggested a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] are simultaneous while the one in {} are mutual exclusive. =20 Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in what we want to describe.=20 =20 I agree with marks suggestion to write it up like this:=20 {VC1,VC5} {VC3,VC5} {VC4,VC5} =20 Cheers=20 =20 -Espen=20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? =20 I would rather not complicate this with Boolean algebra. Mark =20 From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? =20 Hi Espen, This is different since now you have a combination of simultaneous set and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} =20 This is not what Mark was proposing and this expands the representation to be more in line with Boolean algebra in which case we will need to define the syntax for (AND, OR, XOR,..) This will allow having Mark example as=20 {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} =20 The selection becomes one from each OR and all or some of the AND. =20 Do we want to go to this syntax? =20 =20 Roni =20 =20 From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]=20 Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? =20 I think that mutual exclusive sets can be used to model the example 11.1 in the framework document. A snippet from the document <>=20 =20 In the example the main thing to model is that a selection of VC5 has side effects and basically exclude some of the other alternatives=20 * VC5 exclude VC1; VC1 and VC5 is the same physical camera so they cannot be sent at the same time.=20 * VC5 excludes VC3; Since the middle camera does not capture the middle segment anymore, and segment switching into middle segment is not possible anymore * VC5 excludes VC4; A composed view cannot be rendered since VC1 does not capture the middle segment anymore.=20 =20 In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax=20 =20 Cheers=20 =20 -Espen =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? =20 Hi Mark, This is a good example for shorter Mutual exclusive set but taking the example from the framework draft =20 {VC0, VC1, VC2, VC3, VC4, VC6} =20 {VC0, VC2, VC5, VC6} =20 Will have as exclusive set =20 {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} =20 As far as I remember my Boolean algebra the optimized number of entries may be different if we limit ourselves to use either representations. So if we really want to optimize the number of entries we can use Boolean equations to represent the relations. Otherwise it does not matter which method you choose and we should look at how we use this information. The important issue in not only the representation but it is how to do does the selection. =20 In the case of simultaneous set you choose a line or part of it, very simple!!! =20 In the case of mutually exclusive set it is not easy since you cannot just select one MC from each row (not in your example which is one case but in the example from the framework draft), you will need to combine them to Mutual exclusive sets.=20 =20 This is what I claimed in the previous email you sent, and why I prefer simultaneous set. I strongly object to using mutually exclusive sets unless you can explain how you can have an easy select criteria.=20 The capture sets are not providing a full picture but just a subset of the full options that are recommended by the provider. =20 Roni =20 =20 =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? =20 This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. =20 Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. =20 Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. =20 In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} =20 With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} =20 Does anybody see any advantage or disadvantage to this? =20 Mark ------_=_NextPart_001_01CD086B.344BA86E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roni, in my example I only ment to express that = VC5 cannot be sent at the same time as VC1, VC3 or VC4. I did not intend = [] to indicate simultaneous.  

 

So Marks suggested = notation is compact, easy to understand and cover the example from the = framework.

 

-Espen =

 

 

From:= Roni even = [mailto:Even.roni@huawei.com]
Sent: 22. mars 2012 = 20:59
To: Espen Berger (espeberg); Duckworth, Mark; = clue@ietf.org
Subject: RE: [clue] Simultaneous set, or = mutually exclusive set?

 

= Espen,

= I am confused now since for the example from the framework you suggested = a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] are simultaneous while = the one in {} are mutual exclusive.=

=  

Roni=

= From:= clue-bounces@ietf.org = [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) = [espeberg@cisco.com]
Sent: Thursday, March 22, 2012 = 18:20
To: Duckworth, Mark; clue@ietf.org
Subject: Re: = [clue] Simultaneous set, or mutually exclusive set?

No Boolean algebra is = needed. I do not think we need that complexity in what we want to = describe.

 

I agree with marks = suggestion to write it up like this:

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}

 

Cheers

 

-Espen

 

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Duckworth, Mark
Sent: 22. mars 2012 = 16:19
To: clue@ietf.org
Subject: Re: = [clue] Simultaneous set, or mutually exclusive set?

 

I would = rather not complicate this with Boolean algebra.

Mark

 

= From:= Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: = Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger = (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] = Simultaneous set, or mutually exclusive set?

 

Hi = Espen,

This is = different since now you have a combination  of simultaneous set =  and mutual exclusive. Like {VC5 = OR (VC1 AND VC3 AND VC4)}   

This is not = what Mark was proposing and this expands the representation to be more = in line with Boolean algebra in which case we will need to define the = syntax for (AND, OR, XOR,..)

This will allow having Mark example = as

{VC1 OR VC2} = AND {VC3 OR VC4} AND {VC5 OR VC6}

 

The selection = becomes one from each OR and all or some of the AND.

 

Do we want to = go to this syntax?

 

 

Roni

 

 

= From:= Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: = Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, = Mark; clue@ietf.org
Subject: RE: [clue] = Simultaneous set, or mutually exclusive set?

 

I think that mutual = exclusive sets can be used to model the example 11.1 in the framework = document.  A snippet from the document <<VC5 cannot be used = at the same time as VC1 or VC3 or  VC4.>>

 

In the example the main = thing to model is that a selection of VC5 has side effects and basically = exclude some of the other alternatives

·       &= nbsp;  VC5 exclude VC1; VC1 = and VC5 is the same physical camera so they cannot be sent at the same = time.

·       &= nbsp; VC5 excludes VC3; Since the = middle camera does not capture the middle segment anymore, and segment = switching into middle segment is not possible anymore

·       &= nbsp; VC5 excludes VC4; A composed = view cannot be rendered since VC1 does not capture the middle segment = anymore.

 

In other terms; = Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be = written as

{VC5, [VC1, VC3, VC4] } =   // or some other nice syntax

 

Cheers

 

-Espen  =

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: 22. mars 2012 09:13
To: = 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] = Simultaneous set, or mutually exclusive set?

 

Hi = Mark,

This is a = good example for shorter Mutual exclusive set but taking the = example from the framework draft

 

{VC0, VC1, VC2, VC3, VC4, VC6}

 

      {VC0, VC2, VC5, VC6}

 

Will have as exclusive set

 

{VC0}

{VC1,VC5}

{VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}

 

As far as I remember my Boolean algebra the optimized number of entries = may be different if we limit ourselves to use either representations. So = if we really want to optimize the number of entries we can use Boolean = equations to represent the relations. Otherwise it does not matter which = method you choose and we should look at how we use this = information.

The important issue in not only the representation but it  is how = to do does the selection.

 

In the case of simultaneous set you choose a line or part of it, very = simple!!!

 

In the case of mutually exclusive set it is not easy since you cannot = just select one MC from each row (not in your example which is one case = but in the example from the framework draft), you will need to combine = them to Mutual exclusive sets.

 

This is what I claimed in the previous email you sent, and why I prefer = simultaneous set. I strongly object to using mutually exclusive sets = unless you can explain how you can have an easy select criteria. =

The capture sets are not providing a full picture but just a subset of = the full options that are recommended by the provider.

 

Roni

 

 

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 = AM
To: clue@ietf.org
Subject: [clue] = Simultaneous set, or mutually exclusive set?

 

This is a = follow on to the email thread with subject ‘propose "mutually = exclusive" attribute to replace simutaneous sets’.  It = seemed like that thread didn’t have any agreement.  So = I’ll suggest a simpler change to see what you think.  This is = motivated by a discussion at the interim meeting where I thought a few = people were in favor of this.

 

Instead of = conveying the information about which media captures can be used at the = same time with “simultaneous sets”, do it instead with = “mutually exclusive sets”.  The purpose is to have a = more concise way to indicate which media captures cannot be used at the = same time, which we believe scales better than the simultaneous set idea = when there are multiple mutually exclusive constraints.

 

Here is an = example of the difference.  Suppose a provider is advertising six = video captures.  The provider wants to say that VC1 and VC2 = can’t be used at the same time.  And VC3 and VC4 can’t = be used at the same time.  And VC5 and VC6 can’t be used at = the same time.

 

In = simultaneous sets it would be expressed like this:

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

 

With mutually = exclusive sets, it would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody = see any advantage or disadvantage to this?

 

Mark

------_=_NextPart_001_01CD086B.344BA86E-- From Even.roni@huawei.com Thu Mar 22 22:33:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B3A21E8013 for ; Thu, 22 Mar 2012 22:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epVK3XFLH94Q for ; Thu, 22 Mar 2012 22:33:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 229BE21E8039 for ; Thu, 22 Mar 2012 22:33:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEH92313; Fri, 23 Mar 2012 01:33:34 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:30:56 -0700 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:30:53 -0700 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.202]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 13:30:49 +0800 From: Roni even To: "Espen Berger (espeberg)" , "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlwAAWQ5QABOSnd8= Date: Fri, 23 Mar 2012 05:30:49 +0000 Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> , <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: multipart/alternative; boundary="_000_EADCEEE0AE4A7F46BD61061696794D9819E49289szxeml536mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:33:36 -0000 --_000_EADCEEE0AE4A7F46BD61061696794D9819E49289szxeml536mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Espen, This is not true!!!. using mark suggesting it will look like {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} If you want it to look like {VC5, [VC1, VC3, VC4] } you will need to define something which is not only mutual exclusive. But a= lso simultaneous at the same time since [vc,vc3,vc4] are simultaneous in th= is case Roni ________________________________ From: Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 22:29 To: Roni even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Roni, in my example I only ment to express that VC5 cannot be sent at the s= ame time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. So Marks suggested notation is compact, easy to understand and cover the ex= ample from the framework. -Espen From: Roni even [mailto:Even.roni@huawei.com] Sent: 22. mars 2012 20:59 To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, I am confused now since for the example from the framework you suggested a = mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones i= n the [] are simultaneous while the one in {} are mutual exclusive. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in wha= t we want to describe. I agree with marks suggestion to write it up like this: {VC1,VC5} {VC3,VC5} {VC4,VC5} Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives =95 VC5 exclude VC1; VC1 and VC5 is the same physical camera so th= ey cannot be sent at the same time. =95 VC5 excludes VC3; Since the middle camera does not capture the = middle segment anymore, and segment switching into middle segment is not po= ssible anymore =95 VC5 excludes VC4; A composed view cannot be rendered since VC1 = does not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject =91propose "mutually e= xclusive" attribute to replace simutaneous sets=92. It seemed like that th= read didn=92t have any agreement. So I=92ll suggest a simpler change to se= e what you think. This is motivated by a discussion at the interim meeting= where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with =93simultaneous sets=94, do it instead with =93mutua= lly exclusive sets=94. The purpose is to have a more concise way to indica= te which media captures cannot be used at the same time, which we believe s= cales better than the simultaneous set idea when there are multiple mutuall= y exclusive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can=92t be us= ed at the same time. And VC3 and VC4 can=92t be used at the same time. An= d VC5 and VC6 can=92t be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_EADCEEE0AE4A7F46BD61061696794D9819E49289szxeml536mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Espen,

This is not true!!!.  using mark suggesting it will look like

 

From: Roni even [mailt= o:Even.roni@huawei.com]
Sent: 22. mars 2012 20:59
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Espen,

I am confused now since for the example from the framework you su= ggested a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] are simulta= neous while the one in {} are mutual exclusive.

 

Roni

From:= clue-bounces@iet= f.org [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) [esp= eberg@cisco.com]
Sent: Thursday, March 22, 2012 18:20
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

No Boolean algebra is= needed. I do not think we need that complexity in what we want to describe= .

 

I agree with marks su= ggestion to write it up like this:

{VC1,V= C5}

{VC3,V= C5}

{VC4,V= C5}

 

Cheers

 

-Espen

 

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 22. mars 2012 16:19
To: clue@ietf.org=
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

 

I woul= d rather not complicate this with Boolean algebra.

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Hi Espen= ,

This is = different since now you have a combination  of simultaneous set  = and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)}  &n= bsp;

This is = not what Mark was proposing and this expands the representation to be more = in line with Boolean algebra in which case we will need to define the synta= x for (AND, OR, XOR,..)

This wil= l allow having Mark example as

{VC1 OR = VC2} AND {VC3 OR VC4} AND {VC5 OR VC6}<= /span>

 

The sele= ction becomes one from each OR and all or some of the AND.

 

Do we wa= nt to go to this syntax?

 

 

Roni

 

 

From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

I think that mutual e= xclusive sets can be used to model the example 11.1 in the framework docume= nt.  A snippet from the document <<VC5 cannot be used at the sam= e time as VC1 or VC3 or  VC4.>>

 

In the example the ma= in thing to model is that a selection of VC5 has side effects and basically= exclude some of the other alternatives

=B7   = ;       VC5 exclude VC1; VC1 and VC5 is= the same physical camera so they cannot be sent at the same time.

=B7   = ;      VC5 excludes VC3; Since the middle ca= mera does not capture the middle segment anymore, and segment switching int= o middle segment is not possible anymore

=B7   = ;      VC5 excludes VC4; A composed view can= not be rendered since VC1 does not capture the middle segment anymore.

 

In other terms; Selec= ting VC5 excludes usage of capture VC1, VC3, VC4 which could be written as<= /span>

{VC5, [VC1, VC3, VC4]= }   // or some other nice syntax

 

Cheers

 

-Espen  <= span style=3D"COLOR: black">

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

 

Hi Mar= k,

This i= s a good example for shorter Mutual exclusive set but taking the example from th= e framework draft

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM
To: clue@ietf.org=
Subject: [clue] Simultaneous set, or mutually exclusive set?<= span style=3D"COLOR: black">

 

This is = a follow on to the email thread with subject =91propose "mutually excl= usive" attribute to replace simutaneous sets=92.  It seemed like = that thread didn=92t have any agreement.  So I=92ll suggest a simpler change to see what you think.  This is motivated by a discuss= ion at the interim meeting where I thought a few people were in favor of th= is.

 

Instead = of conveying the information about which media captures can be used at the = same time with =93simultaneous sets=94, do it instead with =93mutually excl= usive sets=94.  The purpose is to have a more concise way to indicate which media captures cannot be used at the same ti= me, which we believe scales better than the simultaneous set idea when ther= e are multiple mutually exclusive constraints.

 

Here is = an example of the difference.  Suppose a provider is advertising six v= ideo captures.  The provider wants to say that VC1 and VC2 can=92t be = used at the same time.  And VC3 and VC4 can=92t be used at the same time.  And VC5 and VC6 can=92t be used at the same time.<= /span>

 

In sim= ultaneous sets it would be expressed like this:

{VC1, = VC3, VC5}

{VC1, = VC4, VC5}

{VC1, = VC3, VC6}

{VC1, = VC4, VC6}

{VC2, = VC3, VC5}

{VC2, = VC4, VC5}

{VC2, = VC3, VC6}

{VC2, = VC4, VC6}

 

With mut= ually exclusive sets, it would be expressed like this:

{VC1, VC= 2}

{VC3, VC= 4}

{VC5, VC= 6}

 

Does any= body see any advantage or disadvantage to this?

 

Mark

--_000_EADCEEE0AE4A7F46BD61061696794D9819E49289szxeml536mbxchi_-- From Mark.Duckworth@polycom.com Fri Mar 23 06:25:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1045A21F8541 for ; Fri, 23 Mar 2012 06:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E89YeVNnSjwL for ; Fri, 23 Mar 2012 06:25:11 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5A40721F8542 for ; Fri, 23 Mar 2012 06:25:11 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 23 Mar 2012 06:25:11 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 23 Mar 2012 06:25:09 -0700 Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlwAAWQ5QABOSnd8AEIvJoA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:25:16 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Maybe I'm not being clear about my suggestion. With my mutually exclusive set suggestion, for this example, the mutually e= xclusive sets are: {VC1,VC5} - meaning VC1 and VC5 cannot be used at same time {VC3,VC5} - meaning VC3 and VC5 cannot be used at same time {VC4,VC5} - meaning VC4 and VC5 cannot be used at same time I don't know what you mean by adding something like {VC0} into the list of = mutually exclusive sets. In my proposal, that has no meaning. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Friday, March 23, 2012 1:31 AM To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, This is not true!!!. using mark suggesting it will look like {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} If you want it to look like {VC5, [VC1, VC3, VC4] } you will need to define something which is not only mutual exclusive. But a= lso simultaneous at the same time since [vc,vc3,vc4] are simultaneous in th= is case Roni ________________________________ From: Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 22:29 To: Roni even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Roni, in my example I only ment to express that VC5 cannot be sent at the s= ame time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. So Marks suggested notation is compact, easy to understand and cover the ex= ample from the framework. -Espen From: Roni even [mailto:Even.roni@huawei.com] Sent: 22. mars 2012 20:59 To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, I am confused now since for the example from the framework you suggested a = mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones i= n the [] are simultaneous while the one in {} are mutual exclusive. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in wha= t we want to describe. I agree with marks suggestion to write it up like this: {VC1,VC5} {VC3,VC5} {VC4,VC5} Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives * VC5 exclude VC1; VC1 and VC5 is the same physical camera so they= cannot be sent at the same time. * VC5 excludes VC3; Since the middle camera does not capture the mi= ddle segment anymore, and segment switching into middle segment is not poss= ible anymore * VC5 excludes VC4; A composed view cannot be rendered since VC1 do= es not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject 'propose "mutually exc= lusive" attribute to replace simutaneous sets'. It seemed like that thread= didn't have any agreement. So I'll suggest a simpler change to see what y= ou think. This is motivated by a discussion at the interim meeting where I= thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with "simultaneous sets", do it instead with "mutually ex= clusive sets". The purpose is to have a more concise way to indicate which= media captures cannot be used at the same time, which we believe scales be= tter than the simultaneous set idea when there are multiple mutually exclus= ive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can't be used= at the same time. And VC3 and VC4 can't be used at the same time. And VC= 5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

Maybe I’m not being clear about my suggestion.

With = my mutually exclusive set suggestion, for this example, the mutually exclus= ive sets are:

{VC1,VC5} – meaning VC1 and VC5 cannot be used at same tim= e

{VC3,VC5} – meaning VC= 3 and VC5 cannot be used at same time

{VC4,VC5} – meaning VC4 and VC5 cannot be used at same time

 

I don’t know what you= mean by adding something like {VC0} into the list of mutually exclusive se= ts.  In my proposal, that has no meaning.

 

Mark

<= p class=3DMsoNormal> <= /p>

From: Roni even [mailto:Even.ron= i@huawei.com]
Sent: Friday, March 23, 2012 1:31 AM
To:= Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject:= RE: [clue] Simultaneous set, or mutually exclusive set?<= /p>

 

Espen,

This is not true!!!.=   using mark suggesting it will look like

 

{VC0}=

{VC1,VC5}

{VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}

 

If you want it to lo= ok like

 

 

{VC5, [VC1, VC3, VC4] }

&n= bsp;

you will need to define something which is not only mutual exclu= sive. But also simultaneous at the same time since [vc,vc3,vc4] are&nb= sp;simultaneous in this case<= /p>

 

Roni=

=  

Fr= om: Espen Berger (espeberg) [espeberg@cisco.com= ]
Sent: Thursday, March 22, 2012 22:29
To: Roni even; D= uckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous se= t, or mutually exclusive set?=

Roni, in my example I only ment to express that VC5 cannot be sent= at the same time as VC1, VC3 or VC4. I did not intend [] to indicate simul= taneous.  <= /span>

&nb= sp;

So Marks suggested notation is compact, easy to understand an= d cover the example from the framework.

 

-Espen

 

 

From: Roni even [mailt= o:Even.roni@huawei.com]
Sent: 22. mars 2012 20:59
To: = Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: = RE: [clue] Simultaneous set, or mutually exclusive set?

 

Espen,

I am confused now since for= the example from the framework you suggested a mix of simultaneous an= d mutual exclusive {VC5, [VC1, VC3, VC4] } the on= es in the [] are simultaneous while the one in {} are mutual exclusive= .

<= span lang=3DEN-GB style=3D'color:black'> 

Roni

<= /span>

No Boolean algebra is needed. I do not think we need that complexity = in what we want to describe.

 

I agree with marks suggestion to write it up li= ke this: =

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}

 

Cheers

 

-Espen

 

 

 

I would rather not complicate this with Boolean algebra.

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger= (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or= mutually exclusive set?

 

Hi Espen,

Th= is is different since now you have a combination  of simultaneous set =  and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)}   

This is not what Mark was prop= osing and this expands the representation to be more in line with Boolean a= lgebra in which case we will need to define the syntax for (AND, OR, XOR,..= )

This will allow having Mark ex= ample as =

{VC1 OR VC2} AND {VC3 = OR VC4} AND {VC5 OR VC6}

 

The selection becomes one from each OR and all or some of the AND.<= /span>

 

Do we want to go = to this syntax?<= /span>

&nb= sp;

 

Roni

=  

 

From: Espen Berger (espeberg) [mailto:espeberg@cisco.com<= /a>]
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni E= ven; Duckworth, Mark; cl= ue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually= exclusive set?<= /span>

 

I think that mutual exclusive sets can be used to= model the example 11.1 in the framework document.  A snippet from the= document <<VC5 cannot be used at the same time as VC1 or VC3 or &nbs= p;VC4.>> <= /span>

&nb= sp;

In the example the main thing to model is that a selection of= VC5 has side effects and basically exclude some of the other alternatives =

·          VC5 exclude VC1; VC1 and VC5 is the same phy= sical camera so they cannot be sent at the same time.

·   &n= bsp;     VC5 excludes VC3; Since the middle camera does not capture the middle s= egment anymore, and segment switching into middle segment is not possible a= nymore

·         VC5 excludes VC4; A composed view cannot b= e rendered since VC1 does not capture the middle segment anymore.

 

In other t= erms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could be = written as

{VC5, = [VC1, VC3, VC4] }   // or some other nice syntax

=  

Cheers

 

=

-Espen = ;

 

From: = clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: = 22. mars 2012 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue= ] Simultaneous set, or mutually exclusive set?

<= span lang=3DEN-GB style=3D'color:black'> 

Hi Mark,

This is a good example for shorter Mutual exc= lusive set but taking the example from the framework draft

<= span lang=3DEN-GB style=3D'color:black'> 

{VC0, VC1, VC2, VC3, VC4, VC6}

 

      {VC0, VC2, VC5, VC6}

 <= /span>

Will have as exclusive set

 <= /p>

{VC0}

{VC1,VC5}

{VC2}<= o:p>

{VC3,VC5}

{VC4,VC5}

{VC6}

 

As far as I remember my Boolean algebra the optimized number o= f entries may be different if we limit ourselves to use either representati= ons. So if we really want to optimize the number of entries we can use Bool= ean equations to represent the relations. Otherwise it does not matter whic= h method you choose and we should look at how we use this information.

The important issue in not only the representation but= it  is how to do does the selection.

 

In the case of simultaneous set you choose a line or part of i= t, very simple!!!

 

In the case of m= utually exclusive set it is not easy since you cannot just select one MC fr= om each row (not in your example which is one case but in the example from = the framework draft), you will need to combine them to Mutual exclusive set= s.

 <= /o:p>

This is what I claimed in the = previous email you sent, and why I prefer simultaneous set. I strongly obje= ct to using mutually exclusive sets unless you can explain how you can have= an easy select criteria. <= o:p>

The capture sets are not = providing a full picture but just a subset of the full options that are rec= ommended by the provider.

 

Roni

 =

&n= bsp;

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Beha= lf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM<= br>To: clue@ietf.= org
Subject: [clue] Simultaneous set, or mutually exclusive s= et?

&nb= sp;

T= his is a follow on to the email thread with subject ‘propose "mu= tually exclusive" attribute to replace simutaneous sets’.  = It seemed like that thread didn’t have any agreement.  So I̵= 7;ll suggest a simpler change to see what you think.  This is motivate= d by a discussion at the interim meeting where I thought a few people were = in favor of this.

&= nbsp;

Instead of conveying the information about which media captures can be use= d at the same time with “simultaneous sets”, do it instead with= “mutually exclusive sets”.  The purpose is to have a more= concise way to indicate which media captures cannot be used at the same ti= me, which we believe scales better than the simultaneous set idea when ther= e are multiple mutually exclusive constraints.

 

Here is an example of the difference.  S= uppose a provider is advertising six video captures.  The provider wan= ts to say that VC1 and VC2 can’t be used at the same time.  And = VC3 and VC4 can’t be used at the same time.  And VC5 and VC6 can= ’t be used at the same time.

 

In simultaneous sets it would be expressed like this:<= /span>

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3= , VC5}

{VC2, VC4, VC5}<= span lang=3DEN-GB style=3D'color:black'>

{VC2, VC3, VC6}

{VC2, VC4, VC6}

 

With mutually exclusive sets, it would be expressed = like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any advantage or disadvantage to this?

 

Mark

=
= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21CRPMBOXPRD01p_-- From Even.roni@huawei.com Fri Mar 23 06:40:15 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C0A21F847B for ; Fri, 23 Mar 2012 06:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RovokcWFkGZ2 for ; Fri, 23 Mar 2012 06:40:14 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C718C21F849B for ; Fri, 23 Mar 2012 06:40:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEQ18212; Fri, 23 Mar 2012 09:40:13 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 06:38:57 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 06:38:55 -0700 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.202]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 21:38:48 +0800 From: Roni even To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlwAAWQ5QABOSnd8AEIvJoAAAjiTn Date: Fri, 23 Mar 2012 13:38:47 +0000 Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> , <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: multipart/alternative; boundary="_000_EADCEEE0AE4A7F46BD61061696794D9819E493D0szxeml536mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:40:15 -0000 --_000_EADCEEE0AE4A7F46BD61061696794D9819E493D0szxeml536mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mark, the discussion is about the example in the framework draft and how it shoul= d be specified using only mutual exclusive set Simultaneous set {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Friday, March 23, 2012 15:25 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Roni, Maybe I=92m not being clear about my suggestion. With my mutually exclusive set suggestion, for this example, the mutually e= xclusive sets are: {VC1,VC5} =96 meaning VC1 and VC5 cannot be used at same time {VC3,VC5} =96 meaning VC3 and VC5 cannot be used at same time {VC4,VC5} =96 meaning VC4 and VC5 cannot be used at same time I don=92t know what you mean by adding something like {VC0} into the list o= f mutually exclusive sets. In my proposal, that has no meaning. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Friday, March 23, 2012 1:31 AM To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, This is not true!!!. using mark suggesting it will look like {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} If you want it to look like {VC5, [VC1, VC3, VC4] } you will need to define something which is not only mutual exclusive. But a= lso simultaneous at the same time since [vc,vc3,vc4] are simultaneous in th= is case Roni ________________________________ From: Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 22:29 To: Roni even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Roni, in my example I only ment to express that VC5 cannot be sent at the s= ame time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. So Marks suggested notation is compact, easy to understand and cover the ex= ample from the framework. -Espen From: Roni even [mailto:Even.roni@huawei.com] Sent: 22. mars 2012 20:59 To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, I am confused now since for the example from the framework you suggested a = mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones i= n the [] are simultaneous while the one in {} are mutual exclusive. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in wha= t we want to describe. I agree with marks suggestion to write it up like this: {VC1,VC5} {VC3,VC5} {VC4,VC5} Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives =95 VC5 exclude VC1; VC1 and VC5 is the same physical camera so th= ey cannot be sent at the same time. =95 VC5 excludes VC3; Since the middle camera does not capture the = middle segment anymore, and segment switching into middle segment is not po= ssible anymore =95 VC5 excludes VC4; A composed view cannot be rendered since VC1 = does not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject =91propose "mutually e= xclusive" attribute to replace simutaneous sets=92. It seemed like that th= read didn=92t have any agreement. So I=92ll suggest a simpler change to se= e what you think. This is motivated by a discussion at the interim meeting= where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with =93simultaneous sets=94, do it instead with =93mutua= lly exclusive sets=94. The purpose is to have a more concise way to indica= te which media captures cannot be used at the same time, which we believe s= cales better than the simultaneous set idea when there are multiple mutuall= y exclusive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can=92t be us= ed at the same time. And VC3 and VC4 can=92t be used at the same time. An= d VC5 and VC6 can=92t be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_EADCEEE0AE4A7F46BD61061696794D9819E493D0szxeml536mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Mark,

the discussion is about the example in the framework draft<= /a> and how it should be specified using only mutual exclusive set

 

Simultaneous set

From: Roni even [mailto:Even.roni@huawei.com]
Sent: Friday, March 23, 2012 1:31 AM
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Espen,

This is not true!!!.  using mark suggesting i= t will look like

 

From: Espen Berger (espeberg) [espeberg@cisco.com]
Sent: Thursday, March 22, 2012 22:29
To: Roni even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

Roni, = in my example I only ment to express that VC5 cannot be sent at the same ti= me as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous.  =

&= nbsp;

So Mar= ks suggested notation is compact, easy to understand and cover the example = from the framework.

&= nbsp;

-Espen=

&= nbsp;

&= nbsp;

From: Roni even [mailto:= Even.roni@huawei.com]
Sent: 22. mars 2012 20:59
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

Espen,

I am confused now since for the example from the f= ramework you suggested a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] a= re simultaneous while the one in {} are mutual exclusive.

 

Roni

From: clue-bounces@iet= f.org [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) [esp= eberg@cisco.com]
Sent: Thursday, March 22, 2012 18:20
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

No Boo= lean algebra is needed. I do not think we need that complexity in what we w= ant to describe.

&= nbsp;

I agre= e with marks suggestion to write it up like this:

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}

&= nbsp;

Cheers=

&= nbsp;

-Espen=

&= nbsp;

&= nbsp;

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 22. mars 2012 16:19
To: clue@ietf.org=
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

I would rather not co= mplicate this with Boolean algebra.

Mark

&= nbsp;

From: Roni Even [mailto:ron.even.tlv@gm= ail.com]
Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

Hi Espen,

This is different since= now you have a combination  of simultaneous set  and mutual excl= usive. Like {VC5 OR (VC1 AND VC3 AND= VC4)}   

This is not what Mark w= as proposing and this expands the representation to be more in line with Bo= olean algebra in which case we will need to define the syntax for (AND, OR,= XOR,..)

This will allow having = Mark example as

{VC1 OR VC2} AND {VC3 O= R VC4} AND {VC5 OR VC6}<= /span>

&= nbsp;

The selection becomes o= ne from each OR and all or some of the AND.

&= nbsp;

Do we want to go to thi= s syntax?

&= nbsp;

&= nbsp;

Roni

&= nbsp;

&= nbsp;

From: Espen Berger (espe= berg) [mailto:espeb= erg@cisco.com]
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

I thin= k that mutual exclusive sets can be used to model the example 11.1 in the f= ramework document.  A snippet from the document <<VC5 cannot be = used at the same time as VC1 or VC3 or  VC4.>>

&= nbsp;

In the= example the main thing to model is that a selection of VC5 has side effect= s and basically exclude some of the other alternatives

=B7          VC5 exclude VC1;= VC1 and VC5 is the same physical camera so they cannot be sent at the same= time.

=B7         VC5 excludes VC3; Sinc= e the middle camera does not capture the middle segment anymore, and segmen= t switching into middle segment is not possible anymore

=B7         VC5 excludes VC4; A co= mposed view cannot be rendered since VC1 does not capture the middle segmen= t anymore.

&= nbsp;

In oth= er terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could= be written as

{VC5, = [VC1, VC3, VC4] }   // or some other nice syntax

&= nbsp;

Cheers=

&= nbsp;

-Espen=  

&= nbsp;

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

Hi Mark,

This is a good exa= mple for shorter Mutual exclusive set but taking the example from the f= ramework draft

&= nbsp;

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM
To: clue@ietf.org=
Subject: [clue] Simultaneous set, or mutually exclusive set?<= span style=3D"COLOR: black" lang=3D"EN-GB">

&= nbsp;

This is a follow on to = the email thread with subject =91propose "mutually exclusive" att= ribute to replace simutaneous sets=92.  It seemed like that thread did= n=92t have any agreement.  So I=92ll suggest a simpler change to see what you think.  This is motivated by a discussion at the inte= rim meeting where I thought a few people were in favor of this.

&= nbsp;

Instead of conveying th= e information about which media captures can be used at the same time with = =93simultaneous sets=94, do it instead with =93mutually exclusive sets=94.&= nbsp; The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we be= lieve scales better than the simultaneous set idea when there are multiple = mutually exclusive constraints.

&= nbsp;

Here is an example of t= he difference.  Suppose a provider is advertising six video captures.&= nbsp; The provider wants to say that VC1 and VC2 can=92t be used at the sam= e time.  And VC3 and VC4 can=92t be used at the same time.  And VC5 and VC6 can=92t be used at the same time.

&= nbsp;

In simultaneous sets = it would be expressed like this:

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

&= nbsp;

With mutually exclusive= sets, it would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

&= nbsp;

Does anybody see any ad= vantage or disadvantage to this?

&= nbsp;

Mark

--_000_EADCEEE0AE4A7F46BD61061696794D9819E493D0szxeml536mbxchi_-- From Even.roni@huawei.com Fri Mar 23 07:12:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0521F8543 for ; Fri, 23 Mar 2012 07:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhTwXyXF3PeS for ; Fri, 23 Mar 2012 07:12:55 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6F96621F853A for ; Fri, 23 Mar 2012 07:12:55 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEQ20113; Fri, 23 Mar 2012 10:12:55 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 07:11:24 -0700 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 07:11:08 -0700 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.202]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 22:11:25 +0800 From: Roni even To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlwAAWQ5QABOSnd8AEIvJoAAAjiTnAADr1xc= Date: Fri, 23 Mar 2012 14:11:25 +0000 Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> , <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: multipart/alternative; boundary="_000_EADCEEE0AE4A7F46BD61061696794D9819E493E1szxeml536mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:12:57 -0000 --_000_EADCEEE0AE4A7F46BD61061696794D9819E493E1szxeml536mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mark, You need the whole set of relations even {vc0} to have the complete set of = dependencies The simultaneous set is 2 lines wile the mutual exclusive is 3 or 5 lines d= epending on how you want to present it My claim is that in the general case you cannot have an optimal solution us= ing only "OR" or only "AND" you may need a mixture so selecting only one of= them does not provide an optimal solution My view is that by using simultaneous set it is easier for a consumer to se= lect a set it wants to receive since he only need to select a line and ask = for all of it or part of it. For the mutual exclusive he will need first to= build the simultaneous sets Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni even = [Even.roni@huawei.com] Sent: Friday, March 23, 2012 15:38 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Mark, the discussion is about the example in the framework draft and how it shoul= d be specified using only mutual exclusive set Simultaneous set {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Friday, March 23, 2012 15:25 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Roni, Maybe I=92m not being clear about my suggestion. With my mutually exclusive set suggestion, for this example, the mutually e= xclusive sets are: {VC1,VC5} =96 meaning VC1 and VC5 cannot be used at same time {VC3,VC5} =96 meaning VC3 and VC5 cannot be used at same time {VC4,VC5} =96 meaning VC4 and VC5 cannot be used at same time I don=92t know what you mean by adding something like {VC0} into the list o= f mutually exclusive sets. In my proposal, that has no meaning. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Friday, March 23, 2012 1:31 AM To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, This is not true!!!. using mark suggesting it will look like {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} If you want it to look like {VC5, [VC1, VC3, VC4] } you will need to define something which is not only mutual exclusive. But a= lso simultaneous at the same time since [vc,vc3,vc4] are simultaneous in th= is case Roni ________________________________ From: Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 22:29 To: Roni even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Roni, in my example I only ment to express that VC5 cannot be sent at the s= ame time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. So Marks suggested notation is compact, easy to understand and cover the ex= ample from the framework. -Espen From: Roni even [mailto:Even.roni@huawei.com] Sent: 22. mars 2012 20:59 To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, I am confused now since for the example from the framework you suggested a = mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones i= n the [] are simultaneous while the one in {} are mutual exclusive. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in wha= t we want to describe. I agree with marks suggestion to write it up like this: {VC1,VC5} {VC3,VC5} {VC4,VC5} Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives =95 VC5 exclude VC1; VC1 and VC5 is the same physical camera so th= ey cannot be sent at the same time. =95 VC5 excludes VC3; Since the middle camera does not capture the = middle segment anymore, and segment switching into middle segment is not po= ssible anymore =95 VC5 excludes VC4; A composed view cannot be rendered since VC1 = does not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject =91propose "mutually e= xclusive" attribute to replace simutaneous sets=92. It seemed like that th= read didn=92t have any agreement. So I=92ll suggest a simpler change to se= e what you think. This is motivated by a discussion at the interim meeting= where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with =93simultaneous sets=94, do it instead with =93mutua= lly exclusive sets=94. The purpose is to have a more concise way to indica= te which media captures cannot be used at the same time, which we believe s= cales better than the simultaneous set idea when there are multiple mutuall= y exclusive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can=92t be us= ed at the same time. And VC3 and VC4 can=92t be used at the same time. An= d VC5 and VC6 can=92t be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_EADCEEE0AE4A7F46BD61061696794D9819E493E1szxeml536mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Mark,

You need the whole set of relations even {vc0} to have the complete set = of dependencies

The simultaneous set is 2 lines wile the mutual exclusive is= 3 or 5 lines depending on how you want to present it

 

My claim is that in the general case you cannot = have an optimal solution using only "OR" or only "AND" = you may need a mixture so selecting only one of them does not provide<= a> an optimal solution

 

My view is that by using simultaneous set it is easier for a consumer to select a set it wants to receive<= a> since he only need to select a line and ask for all of i= t or part of it. For the mutual exclusive he will need first to build the simultaneous sets

 

Roni

From: clue-bounces@ietf.org [clue-bounces@= ietf.org] on behalf of Roni even [Even.roni@huawei.com]
Sent: Friday, March 23, 2012 15:38
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

Mark,

the discussion is about the example in the framework draft<= /a> and how it should be specified using only mutual exclusive set

 

Simultaneous set

From: Roni even [mailto:Even.roni@huawei.com]
Sent: Friday, March 23, 2012 1:31 AM
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Espen,

This is not true!!!.  using mark suggesting i= t will look like

 

From: Espen Berger (espeberg) [espeberg@cisco.com]
Sent: Thursday, March 22, 2012 22:29
To: Roni even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

Roni, = in my example I only ment to express that VC5 cannot be sent at the same ti= me as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous.  =

&= nbsp;

So Mar= ks suggested notation is compact, easy to understand and cover the example = from the framework.

&= nbsp;

-Espen=

&= nbsp;

&= nbsp;

From: Roni even [mailto:= Even.roni@huawei.com]
Sent: 22. mars 2012 20:59
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

Espen,

I am confused now since for the example from the f= ramework you suggested a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] a= re simultaneous while the one in {} are mutual exclusive.

 

Roni

From: clue-bounces@iet= f.org [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) [esp= eberg@cisco.com]
Sent: Thursday, March 22, 2012 18:20
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

No Boo= lean algebra is needed. I do not think we need that complexity in what we w= ant to describe.

&= nbsp;

I agre= e with marks suggestion to write it up like this:

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}

&= nbsp;

Cheers=

&= nbsp;

-Espen=

&= nbsp;

&= nbsp;

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 22. mars 2012 16:19
To: clue@ietf.org=
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

I would rather not co= mplicate this with Boolean algebra.

Mark

&= nbsp;

From: Roni Even [mailto:ron.even.tlv@gm= ail.com]
Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

Hi Espen,

This is different since= now you have a combination  of simultaneous set  and mutual excl= usive. Like {VC5 OR (VC1 AND VC3 AND= VC4)}   

This is not what Mark w= as proposing and this expands the representation to be more in line with Bo= olean algebra in which case we will need to define the syntax for (AND, OR,= XOR,..)

This will allow having = Mark example as

{VC1 OR VC2} AND {VC3 O= R VC4} AND {VC5 OR VC6}<= /span>

&= nbsp;

The selection becomes o= ne from each OR and all or some of the AND.

&= nbsp;

Do we want to go to thi= s syntax?

&= nbsp;

&= nbsp;

Roni

&= nbsp;

&= nbsp;

From: Espen Berger (espe= berg) [mailto:espeb= erg@cisco.com]
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

I thin= k that mutual exclusive sets can be used to model the example 11.1 in the f= ramework document.  A snippet from the document <<VC5 cannot be = used at the same time as VC1 or VC3 or  VC4.>>

&= nbsp;

In the= example the main thing to model is that a selection of VC5 has side effect= s and basically exclude some of the other alternatives

=B7          VC5 exclude VC1;= VC1 and VC5 is the same physical camera so they cannot be sent at the same= time.

=B7         VC5 excludes VC3; Sinc= e the middle camera does not capture the middle segment anymore, and segmen= t switching into middle segment is not possible anymore

=B7         VC5 excludes VC4; A co= mposed view cannot be rendered since VC1 does not capture the middle segmen= t anymore.

&= nbsp;

In oth= er terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could= be written as

{VC5, = [VC1, VC3, VC4] }   // or some other nice syntax

&= nbsp;

Cheers=

&= nbsp;

-Espen=  

&= nbsp;

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

&= nbsp;

Hi Mark,

This is a good exa= mple for shorter Mutual exclusive set but taking the example from the f= ramework draft

&= nbsp;

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM
To: clue@ietf.org=
Subject: [clue] Simultaneous set, or mutually exclusive set?<= span style=3D"COLOR: black" lang=3D"EN-GB">

&= nbsp;

This is a follow on to = the email thread with subject =91propose "mutually exclusive" att= ribute to replace simutaneous sets=92.  It seemed like that thread did= n=92t have any agreement.  So I=92ll suggest a simpler change to see what you think.  This is motivated by a discussion at the inte= rim meeting where I thought a few people were in favor of this.

&= nbsp;

Instead of conveying th= e information about which media captures can be used at the same time with = =93simultaneous sets=94, do it instead with =93mutually exclusive sets=94.&= nbsp; The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we be= lieve scales better than the simultaneous set idea when there are multiple = mutually exclusive constraints.

&= nbsp;

Here is an example of t= he difference.  Suppose a provider is advertising six video captures.&= nbsp; The provider wants to say that VC1 and VC2 can=92t be used at the sam= e time.  And VC3 and VC4 can=92t be used at the same time.  And VC5 and VC6 can=92t be used at the same time.

&= nbsp;

In simultaneous sets = it would be expressed like this:

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

&= nbsp;

With mutually exclusive= sets, it would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

&= nbsp;

Does anybody see any ad= vantage or disadvantage to this?

&= nbsp;

Mark

--_000_EADCEEE0AE4A7F46BD61061696794D9819E493E1szxeml536mbxchi_-- From Mark.Duckworth@polycom.com Fri Mar 23 07:21:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FB721F8455 for ; Fri, 23 Mar 2012 07:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo0CLtC6IHuf for ; Fri, 23 Mar 2012 07:21:02 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6CB21F851C for ; Fri, 23 Mar 2012 07:21:02 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 23 Mar 2012 07:21:02 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 23 Mar 2012 07:21:00 -0700 Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlwAAWQ5QABOSnd8AEIvJoAAAjiTnAADr1xcAAHVisA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:21:09 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, It sounds like you are making an alternative proposal of your own, because = a mutually exclusive set of {VC0} has no meaning in my proposal. My view is that a consumer that wants to make an easy simple choice should = select a capture scene entry and ask for all or part of it. The simultaneo= us sets or mutually exclusive sets are irrelevant if the consumer chooses f= rom a capture scene entry. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Friday, March 23, 2012 10:11 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Mark, You need the whole set of relations even {vc0} to have the complete set of = dependencies The simultaneous set is 2 lines wile the mutual exclusive is 3 or 5 lines d= epending on how you want to present it My claim is that in the general case you cannot have an optimal solution us= ing only "OR" or only "AND" you may need a mixture so selecting only one of= them does not provide an optimal solution My view is that by using simultaneous set it is easier for a consumer to se= lect a set it wants to receive since he only need to select a line and ask = for all of it or part of it. For the mutual exclusive he will need first to= build the simultaneous sets Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni even = [Even.roni@huawei.com] Sent: Friday, March 23, 2012 15:38 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Mark, the discussion is about the example in the framework draft and how it shoul= d be specified using only mutual exclusive set Simultaneous set {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Friday, March 23, 2012 15:25 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Roni, Maybe I'm not being clear about my suggestion. With my mutually exclusive set suggestion, for this example, the mutually e= xclusive sets are: {VC1,VC5} - meaning VC1 and VC5 cannot be used at same time {VC3,VC5} - meaning VC3 and VC5 cannot be used at same time {VC4,VC5} - meaning VC4 and VC5 cannot be used at same time I don't know what you mean by adding something like {VC0} into the list of = mutually exclusive sets. In my proposal, that has no meaning. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Friday, March 23, 2012 1:31 AM To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, This is not true!!!. using mark suggesting it will look like {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} If you want it to look like {VC5, [VC1, VC3, VC4] } you will need to define something which is not only mutual exclusive. But a= lso simultaneous at the same time since [vc,vc3,vc4] are simultaneous in th= is case Roni ________________________________ From: Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 22:29 To: Roni even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Roni, in my example I only ment to express that VC5 cannot be sent at the s= ame time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. So Marks suggested notation is compact, easy to understand and cover the ex= ample from the framework. -Espen From: Roni even [mailto:Even.roni@huawei.com] Sent: 22. mars 2012 20:59 To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, I am confused now since for the example from the framework you suggested a = mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones i= n the [] are simultaneous while the one in {} are mutual exclusive. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in wha= t we want to describe. I agree with marks suggestion to write it up like this: {VC1,VC5} {VC3,VC5} {VC4,VC5} Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives * VC5 exclude VC1; VC1 and VC5 is the same physical camera so they= cannot be sent at the same time. * VC5 excludes VC3; Since the middle camera does not capture the mi= ddle segment anymore, and segment switching into middle segment is not poss= ible anymore * VC5 excludes VC4; A composed view cannot be rendered since VC1 do= es not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject 'propose "mutually exc= lusive" attribute to replace simutaneous sets'. It seemed like that thread= didn't have any agreement. So I'll suggest a simpler change to see what y= ou think. This is motivated by a discussion at the interim meeting where I= thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with "simultaneous sets", do it instead with "mutually ex= clusive sets". The purpose is to have a more concise way to indicate which= media captures cannot be used at the same time, which we believe scales be= tter than the simultaneous set idea when there are multiple mutually exclus= ive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can't be used= at the same time. And VC3 and VC4 can't be used at the same time. And VC= 5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

It sounds like you are making an alternative proposal o= f your own, because a mutually exclusive set of {VC0} has no meaning in my = proposal.

My view is that a consumer that wants to make an easy simple choice = should select a capture scene entry and ask for all or part of it.  Th= e simultaneous sets or mutually exclusive sets are irrelevant if the consum= er chooses from a capture scene entry.

Mark

 

From: Roni even [mailto:Even.roni@huawei.com= ]
Sent: Friday, March 23, 2012 10:11 AM
To: Duckworth,= Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mut= ually exclusive set?

=  

Mark,

You nee= d the whole set of relations even {vc0} to have the complete set of depende= ncies

The simultaneous set is 2 lines wile= the mutual exclusive is 3 or 5 lines depending on how you want to present = it

 

My clai= m is that in the general case you cannot have an optimal solution= using only "OR" or only "AND" you may need a mixture s= o selecting only one of them does not provide an optimal solution=

 

My view is = that by using simultaneous set it is easier for a consumer to sel= ect a set it wants to receive since he only need to select a line= and ask for all of it or part of it. For the mutual exclusive he will need= first to build the simultaneous sets

&nbs= p;

Roni

From: clu= e-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni even [Even.ron= i@huawei.com]
Sent: Friday, March 23, 2012 15:38
To: Du= ckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set= , or mutually exclusive set?

Mark,

the discussion is about the = example in the framework draft and how it should be specified usi= ng only mutual exclusive set

 <= /span>

Simultaneous set

{VC0, = VC1, VC2, VC3, VC4, VC6}

{VC0, VC2, VC5, VC6}

Will h= ave as exclusive set

{VC0}

{VC1,VC5}

{VC2}<= /span>

{VC3,VC5}

{VC4,VC5}<= o:p>

{VC6}

Roni

From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckwo= rth, Mark [Mark.Duckworth@polycom.com]
Sent: Friday, March 23, 20= 12 15:25
To: clue@ietf.org
Subject: Re: [clue] Simultan= eous set, or mutually exclusive set?

Hi Roni,

Maybe I’m not being clear about my sug= gestion.

With my mutually exclusive set s= uggestion, for this example, the mutually exclusive sets are:

{VC1,VC5} – meaning VC1 and VC5 cannot be used at = same time

{VC3,VC5} – meaning VC3 an= d VC5 cannot be used at same time

{VC4,VC5}= – meaning VC4 and VC5 cannot be used at same time

 

I don’t know what you mean by adding something lik= e {VC0} into the list of mutually exclusive sets.  In my proposal, tha= t has no meaning.

<= p class=3DMsoNormal> 

Mark

 

From: Roni even [mailto:Even.roni@huawei.com]=
Sent: Friday, March 23, 2012 1:31 AM
To: Espen Berger= (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] S= imultaneous set, or mutually exclusive set?

 

Espen,

Thi= s is not true!!!.  using mark suggesting it will look like

 

{VC0}

{= VC1,VC5}

{VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}

 

If you want it to look lik= e

 

 

{VC5, [VC1,= VC3, VC4] }

 

you will nee= d to define something which is not only mutual exclusive. But also&nbs= p;simultaneous at the same time since [vc,vc3,vc4] are simultaneous in= this case

 

Roni

 

From: Espen Berger (espeberg) [espeberg= @cisco.com]
Sent: Thursday, March 22, 2012 22:29
To: Ro= ni even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simul= taneous set, or mutually exclusive set?<= o:p>

Roni, in my example I only ment to express that V= C5 cannot be sent at the same time as VC1, VC3 or VC4. I did not intend [] = to indicate simultaneous.  

 <= /o:p>

So Marks suggested notation is compact, easy to understand and cover t= he example from the framework.

 

-Espen

 

 

From: Roni even [mail= to:Even.roni@huawei.com]
Sent: 22. mars 2012 20:59
To:= Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject:= RE: [clue] Simultaneous set, or mutually exclusive set?

 

Espen,

I am confused now since for the example from the framework you s= uggested a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] are simultaneous w= hile the one in {} are mutual exclusive.=

 

Roni

<= /span>
<= div>

No Bool= ean algebra is needed. I do not think we need that complexity in what we wa= nt to describe.

 

=

I agree wit= h marks suggestion to write it up like this:

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}<= /p>

 

Cheers=

 

-Espen

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Duckworth, Mark
Sent: 22. mars 2012 16:19
To: clue@ietf.org
Su= bject: Re: [clue] Simultaneous set, or mutually exclusive set?

 

I would rather not complicate this wi= th Boolean algebra.

Mark

 

From: Roni Even [mailto:ron.even.tlv@gmail.com]
S= ent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger (esp= eberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutu= ally exclusive set?

 

Hi Espen,

This i= s different since now you have a combination  of simultaneous set &nbs= p;and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)}   

This is not what Mark was proposing and this expands the representation to= be more in line with Boolean algebra in which case we will need to define = the syntax for (AND, OR, XOR,..)

= This will allow having Mark example as

{VC1 OR VC2}= AND {VC3 OR VC4} AND {VC5 OR VC6}

 

The selection becomes one from each OR and = all or some of the AND.

 

Do we want to go to this syntax?

=

 

 =

Roni=

 

 

From: Espen Berger (espeberg) [mailto:espeberg@cisco.com]
Sent: Thursday, March 22= , 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: [= clue] Simultaneous set, or mutually exclusive set?

 

I think that mutual exclusive sets can b= e used to model the example 11.1 in the framework document.  A snippet= from the document <<VC5 cannot be used at the same time as VC1 or VC= 3 or  VC4.>>

 

In = the example the main thing to model is that a selection of VC5 has side eff= ects and basically exclude some of the other alternatives

·    &nb= sp;    &nb= sp;VC5 exclude VC1; VC1 and VC5 is the same physical camera so they cannot = be sent at the same time.

·         VC5 excludes VC3; Since the middle ca= mera does not capture the middle segment anymore, and segment switching int= o middle segment is not possible anymore=

·<= /span>        = ; VC5 excludes VC4; A com= posed view cannot be rendered since VC1 does not capture the middle segment= anymore.

 

In other terms; S= electing VC5 excludes usage of capture VC1, VC3, VC4 which could be written= as

{VC5, [VC1, VC3, VC4] } &n= bsp; // or some other nice syntax <= o:p>

 = ;

Cheers

 <= /p>

-Espen&n= bsp;

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org= ] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13
= To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or = mutually exclusive set?

 

Hi Ma= rk,

This is a good example for short= er Mutual exclusive set but taking the example from the framework draft

<= span style=3D'color:black'> 

{VC0, VC1, VC2, VC3, VC4, VC6}<= o:p>

&n= bsp;

   &n= bsp;  {VC0, VC2, VC5, VC6}

 

Will have as exclusive set

 

{VC0}

{VC1,VC5}<= o:p>

{VC2}

{VC3,V= C5}

{VC4,VC5}

{VC6}<= o:p>

&n= bsp;

As far as I remember= my Boolean algebra the optimized number of entries may be different if we = limit ourselves to use either representations. So if we really want to opti= mize the number of entries we can use Boolean equations to represent the re= lations. Otherwise it does not matter which method you choose and we should= look at how we use this information.

The important issue in not = only the representation but it  is how to do does the selection.

=  

In the case of simultaneous set you choose a line or part of it, = very simple!!!

 

In the case of mutually exclusive set it is n= ot easy since you cannot just select one MC from each row (not in your exam= ple which is one case but in the example from the framework draft), you wil= l need to combine them to Mutual exclusive sets.

 

This is wh= at I claimed in the previous email you sent, and why I prefer simultaneous = set. I strongly object to using mutually exclusive sets unless you can expl= ain how you can have an easy select criteria.

The capture sets a= re not providing a full picture but just a subset of the full options that = are recommended by the provider.

 

Roni

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On= Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:0= 5 AM
To: clue@= ietf.org
Subject: [clue] Simultaneous set, or mutually exclus= ive set?

 =

This is a follow on to= the email thread with subject ‘propose "mutually exclusive"= ; attribute to replace simutaneous sets’.  It seemed like that t= hread didn’t have any agreement.  So I’ll suggest a simple= r change to see what you think.  This is motivated by a discussion at = the interim meeting where I thought a few people were in favor of this.

 

Instea= d of conveying the information about which media captures can be used at th= e same time with “simultaneous sets”, do it instead with “= ;mutually exclusive sets”.  The purpose is to have a more concis= e way to indicate which media captures cannot be used at the same time, whi= ch we believe scales better than the simultaneous set idea when there are m= ultiple mutually exclusive constraints.

 

Here is an example of the difference.&= nbsp; Suppose a provider is advertising six video captures.  The provi= der wants to say that VC1 and VC2 can’t be used at the same time.&nbs= p; And VC3 and VC4 can’t be used at the same time.  And VC5 and = VC6 can’t be used at the same time.

 

In simultaneous sets it would be= expressed like this:<= /p>

{VC1, VC3, VC5}

{VC1, VC4, VC5}

= {VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, = VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

 

With mutual= ly exclusive sets, it would be expressed like this:

{VC1, VC2}=

{VC3, VC4}<= /span>

{VC5, VC6}<= /o:p>

 

Does any= body see any advantage or disadvantage to this?

 

Mark

<= /div>
= --_000_44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72CRPMBOXPRD01p_-- From Even.roni@huawei.com Fri Mar 23 07:46:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2057C21F855F for ; Fri, 23 Mar 2012 07:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ee9wTkUPgorZ for ; Fri, 23 Mar 2012 07:46:41 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ED35121F84D1 for ; Fri, 23 Mar 2012 07:46:40 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEQ22232; Fri, 23 Mar 2012 10:46:40 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 07:45:11 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 23 Mar 2012 07:44:42 -0700 Received: from SZXEML536-MBX.china.huawei.com ([169.254.4.202]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 22:44:57 +0800 From: Roni even To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgB5EJ8wAA1yzoAAAYu2AAAA+j6gAACkZFAACRlRlwAAWQ5QABOSnd8AEIvJoAAAjiTnAADr1xcAAHVisAAAh4RH Date: Fri, 23 Mar 2012 14:44:57 +0000 Message-ID: References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> , <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72@CRPMBOXPRD01.polycom.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.46] Content-Type: multipart/alternative; boundary="_000_EADCEEE0AE4A7F46BD61061696794D9819E493F1szxeml536mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 14:46:43 -0000 --_000_EADCEEE0AE4A7F46BD61061696794D9819E493F1szxeml536mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Mark, I am objecting to your proposed change in the framework from simultaneous s= et to alternative set the reasons are: 1. It is not shorter - this is Boolean algebra you have a set of Boolean co= nditions here, it depends on the conditions that will specify what will hav= e short number of equation and elements in the equations. (I think it is Ka= rnaugh maps that help simplify Boolean algebra expressions) 2. Capture scene do not supply all the simultaneous options since they are = suggestions but the full set is the simultaneous sets 3. Anyhow you can get the full simultaneous set from the mutual exclusive s= et but this require computation. If you really want to optimize than define a syntax that will have both mut= ual exclusive and simultaneous in one description, similar to what Espen su= ggested for the framework example {VC5,[VC1,VC2,VC3}} which even though he = claimed that the values in [] are not simultaneous, practically they are si= nce they can be sent at the same time. This will help with shorter represen= tation since you have two operator to use but is not simple. This is why I think that we should keep the framework as is. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Friday, March 23, 2012 16:21 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Roni, It sounds like you are making an alternative proposal of your own, because = a mutually exclusive set of {VC0} has no meaning in my proposal. My view is that a consumer that wants to make an easy simple choice should = select a capture scene entry and ask for all or part of it. The simultaneo= us sets or mutually exclusive sets are irrelevant if the consumer chooses f= rom a capture scene entry. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Friday, March 23, 2012 10:11 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Mark, You need the whole set of relations even {vc0} to have the complete set of = dependencies The simultaneous set is 2 lines wile the mutual exclusive is 3 or 5 lines d= epending on how you want to present it My claim is that in the general case you cannot have an optimal solution us= ing only "OR" or only "AND" you may need a mixture so selecting only one of= them does not provide an optimal solution My view is that by using simultaneous set it is easier for a consumer to se= lect a set it wants to receive since he only need to select a line and ask = for all of it or part of it. For the mutual exclusive he will need first to= build the simultaneous sets Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni even = [Even.roni@huawei.com] Sent: Friday, March 23, 2012 15:38 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Mark, the discussion is about the example in the framework draft and how it shoul= d be specified using only mutual exclusive set Simultaneous set {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Friday, March 23, 2012 15:25 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Roni, Maybe I=92m not being clear about my suggestion. With my mutually exclusive set suggestion, for this example, the mutually e= xclusive sets are: {VC1,VC5} =96 meaning VC1 and VC5 cannot be used at same time {VC3,VC5} =96 meaning VC3 and VC5 cannot be used at same time {VC4,VC5} =96 meaning VC4 and VC5 cannot be used at same time I don=92t know what you mean by adding something like {VC0} into the list o= f mutually exclusive sets. In my proposal, that has no meaning. Mark From: Roni even [mailto:Even.roni@huawei.com] Sent: Friday, March 23, 2012 1:31 AM To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, This is not true!!!. using mark suggesting it will look like {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} If you want it to look like {VC5, [VC1, VC3, VC4] } you will need to define something which is not only mutual exclusive. But a= lso simultaneous at the same time since [vc,vc3,vc4] are simultaneous in th= is case Roni ________________________________ From: Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 22:29 To: Roni even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Roni, in my example I only ment to express that VC5 cannot be sent at the s= ame time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. So Marks suggested notation is compact, easy to understand and cover the ex= ample from the framework. -Espen From: Roni even [mailto:Even.roni@huawei.com] Sent: 22. mars 2012 20:59 To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Espen, I am confused now since for the example from the framework you suggested a = mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones i= n the [] are simultaneous while the one in {} are mutual exclusive. Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com] Sent: Thursday, March 22, 2012 18:20 To: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? No Boolean algebra is needed. I do not think we need that complexity in wha= t we want to describe. I agree with marks suggestion to write it up like this: {VC1,VC5} {VC3,VC5} {VC4,VC5} Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: 22. mars 2012 16:19 To: clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? I would rather not complicate this with Boolean algebra. Mark From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Thursday, March 22, 2012 11:08 AM To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? Hi Espen, This is different since now you have a combination of simultaneous set an= d mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} This is not what Mark was proposing and this expands the representation to = be more in line with Boolean algebra in which case we will need to define t= he syntax for (AND, OR, XOR,..) This will allow having Mark example as {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} The selection becomes one from each OR and all or some of the AND. Do we want to go to this syntax? Roni From: Espen Berger (espeberg) [mailto:espeberg@cisco.com] Sent: Thursday, March 22, 2012 4:17 PM To: Roni Even; Duckworth, Mark; clue@ietf.org Subject: RE: [clue] Simultaneous set, or mutually exclusive set? I think that mutual exclusive sets can be used to model the example 11.1 in= the framework document. A snippet from the document <> In the example the main thing to model is that a selection of VC5 has side = effects and basically exclude some of the other alternatives =95 VC5 exclude VC1; VC1 and VC5 is the same physical camera so th= ey cannot be sent at the same time. =95 VC5 excludes VC3; Since the middle camera does not capture the = middle segment anymore, and segment switching into middle segment is not po= ssible anymore =95 VC5 excludes VC4; A composed view cannot be rendered since VC1 = does not capture the middle segment anymore. In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which= could be written as {VC5, [VC1, VC3, VC4] } // or some other nice syntax Cheers -Espen From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: 22. mars 2012 09:13 To: 'Duckworth, Mark'; clue@ietf.org Subject: Re: [clue] Simultaneous set, or mutually exclusive set? Hi Mark, This is a good example for shorter Mutual exclusive set but taking the exam= ple from the framework draft {VC0, VC1, VC2, VC3, VC4, VC6} {VC0, VC2, VC5, VC6} Will have as exclusive set {VC0} {VC1,VC5} {VC2} {VC3,VC5} {VC4,VC5} {VC6} As far as I remember my Boolean algebra the optimized number of entries may= be different if we limit ourselves to use either representations. So if we= really want to optimize the number of entries we can use Boolean equations= to represent the relations. Otherwise it does not matter which method you = choose and we should look at how we use this information. The important issue in not only the representation but it is how to do doe= s the selection. In the case of simultaneous set you choose a line or part of it, very simpl= e!!! In the case of mutually exclusive set it is not easy since you cannot just = select one MC from each row (not in your example which is one case but in t= he example from the framework draft), you will need to combine them to Mutu= al exclusive sets. This is what I claimed in the previous email you sent, and why I prefer sim= ultaneous set. I strongly object to using mutually exclusive sets unless yo= u can explain how you can have an easy select criteria. The capture sets are not providing a full picture but just a subset of the = full options that are recommended by the provider. Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject =91propose "mutually e= xclusive" attribute to replace simutaneous sets=92. It seemed like that th= read didn=92t have any agreement. So I=92ll suggest a simpler change to se= e what you think. This is motivated by a discussion at the interim meeting= where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used= at the same time with =93simultaneous sets=94, do it instead with =93mutua= lly exclusive sets=94. The purpose is to have a more concise way to indica= te which media captures cannot be used at the same time, which we believe s= cales better than the simultaneous set idea when there are multiple mutuall= y exclusive constraints. Here is an example of the difference. Suppose a provider is advertising si= x video captures. The provider wants to say that VC1 and VC2 can=92t be us= ed at the same time. And VC3 and VC4 can=92t be used at the same time. An= d VC5 and VC6 can=92t be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark --_000_EADCEEE0AE4A7F46BD61061696794D9819E493F1szxeml536mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Mark,

I am objecting to your proposed change in the framework from simult= aneous set to alternative set

the reasons are:

 

1. It is not shorter - this is Boolean algebra you have a set of&nb= sp;Boolean conditions here, it depends on the conditions that will s= pecify what will have short number of equation and element= s in the equations. (I think it is Karnaugh maps that help simplify Boolean algebra expressions)

2. Capture scene do not supply all the simultaneous<= /a> options since they are suggestions but the full set is the simulta= neous sets

3. Anyhow you can get the full simultaneous set from the mut= ual exclusive set but this require computation.

 

If you really want to optimize than define a syntax that will have both = mutual exclusive and simultaneous in one description, similar t= o what Espen suggested for the framework exa= mple {VC5,[VC1,VC2,VC3}} which even though he claimed that the values in [] are not simultaneous, practi= cally they are since they can be sent at the same time. This= will help with shorter representation since you have two operator to u= se but is not simple.

This is why I think that we should keep the framework as is.

 

Roni

From: clue-bounces@ietf.org [clue-bounces@= ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Friday, March 23, 2012 16:21
To: clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

Hi Roni,

It sounds like you ar= e making an alternative proposal of your own, because a mutually exclusive = set of {VC0} has no meaning in my proposal.

My view is that a con= sumer that wants to make an easy simple choice should select a capture scen= e entry and ask for all or part of it.  The simultaneous sets or mutua= lly exclusive sets are irrelevant if the consumer chooses from a capture scene entry.

Mark

 

From: Roni even [mailto:Even.roni@huawei.com]
Sent: Friday, March 23, 2012 10:11 AM
To: Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Mark,

You need the whole set of relations even {vc0} to have the comple= te set of dependencies

The simultaneous set is 2 lines wile the mutual exclusive is= 3 or 5 lines depending on how you want to present it

 

My claim is that in the general case you cannot have an= optimal solution using only "OR" or only "AND" you may= need a mixture so selecting only one of them does not provide an optimal solution

 

My view is that by using simultaneous set it is ea= sier for a consumer to select a set it wants to receive since he = only need to select a line and ask for all of it or part of it. For the mutual exclusive he will need first to build the simultan= eous sets

 

Roni

From:= clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni even [Even.roni@huawei.com]
Sent: Friday, March 23, 2012 15:38
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

Mark,

the discussion is about the example in the framework dr= aft and how it should be specified using only mutual exclusive set

 

Roni

From:= clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Friday, March 23, 2012 15:25
To: clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

Hi Roni,

Maybe I=92m not being= clear about my suggestion.

With my mutually excl= usive set suggestion, for this example, the mutually exclusive sets are:

{VC1,VC5} =96 meaning= VC1 and VC5 cannot be used at same time

{VC3,VC5} =96 meaning= VC3 and VC5 cannot be used at same time

{VC4,VC5} =96 meaning= VC4 and VC5 cannot be used at same time

 

I don=92t know what y= ou mean by adding something like {VC0} into the list of mutually exclusive = sets.  In my proposal, that has no meaning.

 

Mark

 

From: Roni even [mailto:= Even.roni@huawei.com]
Sent: Friday, March 23, 2012 1:31 AM
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Espen,<= /p>

This is not true!!!.  using mark suggesting i= t will look like

 

From: Espen Berger (espeberg) [espeberg@cisco.com]
Sent: Thursday, March 22, 2012 22:29
To: Roni even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

Roni, = in my example I only ment to express that VC5 cannot be sent at the same ti= me as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous.  =

 

So Mar= ks suggested notation is compact, easy to understand and cover the example = from the framework.

 

-Espen=

 

 

From: Roni even [mailto:= Even.roni@huawei.com]
Sent: 22. mars 2012 20:59
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Espen,<= /p>

I am confused now since for the example from the f= ramework you suggested a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones in the [] a= re simultaneous while the one in {} are mutual exclusive.

 

Roni<= /p>

From: clue-bounces@iet= f.org [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) [esp= eberg@cisco.com]
Sent: Thursday, March 22, 2012 18:20
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

No Boo= lean algebra is needed. I do not think we need that complexity in what we w= ant to describe.

 

I agre= e with marks suggestion to write it up like this:

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}

 

Cheers=

 

-Espen=

 

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 22. mars 2012 16:19
To: clue@ietf.org=
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

 

I would rather not co= mplicate this with Boolean algebra.

Mark

 

From: Roni Even [mailto:ron.even.tlv@gm= ail.com]
Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

Hi Espen,

This is different since= now you have a combination  of simultaneous set  and mutual excl= usive. Like {VC5 OR (VC1 AND VC3 AND= VC4)}   

This is not what Mark w= as proposing and this expands the representation to be more in line with Bo= olean algebra in which case we will need to define the syntax for (AND, OR,= XOR,..)

This will allow having = Mark example as

{VC1 OR VC2} AND {VC3 O= R VC4} AND {VC5 OR VC6}

 

The selection becomes o= ne from each OR and all or some of the AND.

 

Do we want to go to thi= s syntax?

 

 

Roni

 

 

From: Espen Berger (espe= berg) [mailto:espeb= erg@cisco.com]
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

 

I thin= k that mutual exclusive sets can be used to model the example 11.1 in the f= ramework document.  A snippet from the document <<VC5 cannot be = used at the same time as VC1 or VC3 or  VC4.>>

 

In the= example the main thing to model is that a selection of VC5 has side effect= s and basically exclude some of the other alternatives

=B7          VC5 exclude VC1;= VC1 and VC5 is the same physical camera so they cannot be sent at the same= time.

=B7         VC5 excludes VC3; Sinc= e the middle camera does not capture the middle segment anymore, and segmen= t switching into middle segment is not possible anymore

=B7         VC5 excludes VC4; A co= mposed view cannot be rendered since VC1 does not capture the middle segmen= t anymore.

 

In oth= er terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could= be written as

{VC5, = [VC1, VC3, VC4] }   // or some other nice syntax

 

Cheers=

 

-Espen=  

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

 

Hi Mark,

This is a good exa= mple for shorter Mutual exclusive set but taking the example from the f= ramework draft

 

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM
To: clue@ietf.org=
Subject: [clue] Simultaneous set, or mutually exclusive set?<= span style=3D"COLOR: black">

 

This is a follow on to = the email thread with subject =91propose "mutually exclusive" att= ribute to replace simutaneous sets=92.  It seemed like that thread did= n=92t have any agreement.  So I=92ll suggest a simpler change to see what you think.  This is motivated by a discussion at the inte= rim meeting where I thought a few people were in favor of this.

 

Instead of conveying th= e information about which media captures can be used at the same time with = =93simultaneous sets=94, do it instead with =93mutually exclusive sets=94.&= nbsp; The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we be= lieve scales better than the simultaneous set idea when there are multiple = mutually exclusive constraints.

 

Here is an example of t= he difference.  Suppose a provider is advertising six video captures.&= nbsp; The provider wants to say that VC1 and VC2 can=92t be used at the sam= e time.  And VC3 and VC4 can=92t be used at the same time.  And VC5 and VC6 can=92t be used at the same time.

 

In simultaneous sets = it would be expressed like this:=

{VC1, VC3, VC5}

{VC1, VC4, VC5}

{VC1, VC3, VC6}

{VC1, VC4, VC6}

{VC2, VC3, VC5}

{VC2, VC4, VC5}

{VC2, VC3, VC6}

{VC2, VC4, VC6}

 

With mutually exclusive= sets, it would be expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody see any ad= vantage or disadvantage to this?

 

Mark

--_000_EADCEEE0AE4A7F46BD61061696794D9819E493F1szxeml536mbxchi_-- From pkyzivat@alum.mit.edu Fri Mar 23 08:21:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB8F721F84D4 for ; Fri, 23 Mar 2012 08:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyIzTgitcW8o for ; Fri, 23 Mar 2012 08:21:33 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 8042921F84D3 for ; Fri, 23 Mar 2012 08:21:33 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id oymQ1i0031YDfWL593MZBs; Fri, 23 Mar 2012 15:21:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id p3MZ1i01907duvL3g3MZH8; Fri, 23 Mar 2012 15:21:33 +0000 Message-ID: <4F6C94FC.1020206@alum.mit.edu> Date: Fri, 23 Mar 2012 11:21:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:21:38 -0000 Mark, Roni, It seems clear to me that the two of you are not understanding one another. Looking at Mark's original comparison of simultaneous sets vs. mutually exclusive sets, I think one thing is missing from the proposal for mutually exclusive sets: In addition to listing which captures are mutually exclusive, there is a need to enumerate all the captures that are being advertised. Something like: Captures: {V1, V2, V3, V4, V5, V6} Mutual Exclusion: {VC1, VC2}, {VC3, VC4}, {VC5, VC6} Of course there can be a number of ways to optimize the representation of this. For instance, all the captures listed in mutual exclusion sets can be assumed to be advertised, so perhaps it is only necessary to additionally advertise those that aren't so listed. In your case all have been listed in mutual exclusion sets so no others need be listed. But that need not always be the case. This would be especially obvious when there are no mutual exclusion rules. Thanks, Paul (as individual) On 3/23/12 10:21 AM, Duckworth, Mark wrote: > Hi Roni, > > It sounds like you are making an alternative proposal of your own, > because a mutually exclusive set of {VC0} has no meaning in my proposal. > > My view is that a consumer that wants to make an easy simple choice > should select a capture scene entry and ask for all or part of it. The > simultaneous sets or mutually exclusive sets are irrelevant if the > consumer chooses from a capture scene entry. > > Mark > > *From:*Roni even [mailto:Even.roni@huawei.com] > *Sent:* Friday, March 23, 2012 10:11 AM > *To:* Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > Mark, > > You need the whole set of relations even {vc0} to have the complete set > of dependencies > > The simultaneous set is 2 lines wile the mutual exclusive is 3 or 5 > lines depending on how you want to present it > > My claim is that in the general case you cannot have an optimal solution > using only "OR" or only "AND" you may need a mixture so selecting only > one of them does not provide an optimal solution > > My view is that by using simultaneous set it is easier for a consumer to > select a set it wants to receive since he only need to select a line and > ask for all of it or part of it. For the mutual exclusive he will need > first to build the simultaneous sets > > Roni > > ------------------------------------------------------------------------ > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni > even [Even.roni@huawei.com] > *Sent:* Friday, March 23, 2012 15:38 > *To:* Duckworth, Mark; clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > Mark, > > the discussion is about the example in the framework draft and how it > should be specified using only mutual exclusive set > > Simultaneous set > > {VC0, VC1, VC2, VC3, VC4, VC6} > > {VC0, VC2, VC5, VC6} > > Will have as exclusive set > > {VC0} > > {VC1,VC5} > > {VC2} > > {VC3,VC5} > > {VC4,VC5} > > {VC6} > > Roni > > ------------------------------------------------------------------------ > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com] > *Sent:* Friday, March 23, 2012 15:25 > *To:* clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > Hi Roni, > > Maybe I’m not being clear about my suggestion. > > With my mutually exclusive set suggestion, for this example, the > mutually exclusive sets are: > > {VC1,VC5} – meaning VC1 and VC5 cannot be used at same time > > {VC3,VC5} – meaning VC3 and VC5 cannot be used at same time > > {VC4,VC5} – meaning VC4 and VC5 cannot be used at same time > > I don’t know what you mean by adding something like {VC0} into the list > of mutually exclusive sets. In my proposal, that has no meaning. > > Mark > > *From:*Roni even [mailto:Even.roni@huawei.com] > *Sent:* Friday, March 23, 2012 1:31 AM > *To:* Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > Espen, > > This is not true!!!. using mark suggesting it will look like > > {VC0} > > {VC1,VC5} > > {VC2} > > {VC3,VC5} > > {VC4,VC5} > > {VC6} > > If you want it to look like > > {VC5, [VC1, VC3, VC4] } > > you will need to define something which is not only mutual exclusive. > But also simultaneous at the same time since [vc,vc3,vc4] are > simultaneous in this case > > Roni > > ------------------------------------------------------------------------ > > *From:*Espen Berger (espeberg) [espeberg@cisco.com] > *Sent:* Thursday, March 22, 2012 22:29 > *To:* Roni even; Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > Roni, in my example I only ment to express that VC5 cannot be sent at > the same time as VC1, VC3 or VC4. I did not intend [] to indicate > simultaneous. > > So Marks suggested notation is compact, easy to understand and cover the > example from the framework. > > -Espen > > *From:*Roni even [mailto:Even.roni@huawei.com] > *Sent:* 22. mars 2012 20:59 > *To:* Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > Espen, > > I am confused now since for the example from the framework you suggested > a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the > ones in the [] are simultaneous while the one in {} are mutual exclusive. > > Roni > > ------------------------------------------------------------------------ > > *From:*clue-bounces@ietf.org > [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) > [espeberg@cisco.com] > *Sent:* Thursday, March 22, 2012 18:20 > *To:* Duckworth, Mark; clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > No Boolean algebra is needed. I do not think we need that complexity in > what we want to describe. > > I agree with marks suggestion to write it up like this: > > {VC1,VC5} > > {VC3,VC5} > > {VC4,VC5} > > Cheers > > -Espen > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mark > *Sent:* 22. mars 2012 16:19 > *To:* clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > I would rather not complicate this with Boolean algebra. > > Mark > > *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Thursday, March 22, 2012 11:08 AM > *To:* 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org > > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > Hi Espen, > > This is different since now you have a combination of simultaneous set > and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} > > This is not what Mark was proposing and this expands the representation > to be more in line with Boolean algebra in which case we will need to > define the syntax for (AND, OR, XOR,..) > > This will allow having Mark example as > > {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} > > The selection becomes one from each OR and all or some of the AND. > > Do we want to go to this syntax? > > Roni > > *From:*Espen Berger (espeberg) [mailto:espeberg@cisco.com] > *Sent:* Thursday, March 22, 2012 4:17 PM > *To:* Roni Even; Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > I think that mutual exclusive sets can be used to model the example 11.1 > in the framework document. A snippet from the document < used at the same time as VC1 or VC3 or VC4.>> > > In the example the main thing to model is that a selection of VC5 has > side effects and basically exclude some of the other alternatives > > ·VC5 exclude VC1; VC1 and VC5 is the same physical camera so they cannot > be sent at the same time. > > ·VC5 excludes VC3; Since the middle camera does not capture the middle > segment anymore, and segment switching into middle segment is not > possible anymore > > ·VC5 excludes VC4; A composed view cannot be rendered since VC1 does not > capture the middle segment anymore. > > In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 > which could be written as > > {VC5, [VC1, VC3, VC4] } // or some other nice syntax > > Cheers > > -Espen > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even > *Sent:* 22. mars 2012 09:13 > *To:* 'Duckworth, Mark'; clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > Hi Mark, > > This is a good _example_ for shorter Mutual exclusive set but taking the > example from the framework draft > > {VC0, VC1, VC2, VC3, VC4, VC6} > > {VC0, VC2, VC5, VC6} > > Will have as exclusive set > > {VC0} > > {VC1,VC5} > > {VC2} > > {VC3,VC5} > > {VC4,VC5} > > {VC6} > > As far as I remember my Boolean algebra the optimized number of entries > may be different if we limit ourselves to use either representations. So > if we really want to optimize the number of entries we can use Boolean > equations to represent the relations. Otherwise it does not matter which > method you choose and we should look at how we use this information. > > The important issue in not only the representation but it is how to do > does the selection. > > In the case of simultaneous set you choose a line or part of it, very > simple!!! > > In the case of mutually exclusive set it is not easy since you cannot > just select one MC from each row (not in your example which is one case > but in the example from the framework draft), you will need to combine > them to Mutual exclusive sets. > > This is what I claimed in the previous email you sent, and why I prefer > simultaneous set. I strongly object to using mutually exclusive sets > unless you can explain how you can have an easy select criteria. > > The capture sets are not providing a full picture but just a subset of > the full options that are recommended by the provider. > > Roni > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mark > *Sent:* Tuesday, March 20, 2012 12:05 AM > *To:* clue@ietf.org > *Subject:* [clue] Simultaneous set, or mutually exclusive set? > > This is a follow on to the email thread with subject ‘propose "mutually > exclusive" attribute to replace simutaneous sets’. It seemed like that > thread didn’t have any agreement. So I’ll suggest a simpler change to > see what you think. This is motivated by a discussion at the interim > meeting where I thought a few people were in favor of this. > > Instead of conveying the information about which media captures can be > used at the same time with “simultaneous sets”, do it instead with > “mutually exclusive sets”. The purpose is to have a more concise way to > indicate which media captures cannot be used at the same time, which we > believe scales better than the simultaneous set idea when there are > multiple mutually exclusive constraints. > > Here is an example of the difference. Suppose a provider is advertising > six video captures. The provider wants to say that VC1 and VC2 can’t be > used at the same time. And VC3 and VC4 can’t be used at the same time. > And VC5 and VC6 can’t be used at the same time. > > In simultaneous sets it would be expressed like this: > > {VC1, VC3, VC5} > > {VC1, VC4, VC5} > > {VC1, VC3, VC6} > > {VC1, VC4, VC6} > > {VC2, VC3, VC5} > > {VC2, VC4, VC5} > > {VC2, VC3, VC6} > > {VC2, VC4, VC6} > > With mutually exclusive sets, it would be expressed like this: > > {VC1, VC2} > > {VC3, VC4} > > {VC5, VC6} > > Does anybody see any advantage or disadvantage to this? > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Fri Mar 23 08:38:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265B021F853A for ; Fri, 23 Mar 2012 08:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9VZWqh2GYRz for ; Fri, 23 Mar 2012 08:38:34 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id CC19421F8518 for ; Fri, 23 Mar 2012 08:38:33 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Fri, 23 Mar 2012 08:38:33 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 23 Mar 2012 08:38:31 -0700 Thread-Topic: [clue] Simultaneous set, or mutually exclusive set? Thread-Index: Ac0JCKatp3Jwn92mSse3yaD58TeGSAAAR56Q Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCB60F1B@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E72@CRPMBOXPRD01.polycom.com> <4F6C94FC.1020206@alum.mit.edu> In-Reply-To: <4F6C94FC.1020206@alum.mit.edu> 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: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 15:38:38 -0000 Hi Paul, Yes, there would be a list of all the captures somehow, possibly derived fr= om the captures referenced in the capture scenes. I think this will become= more clear as we progress the data model we started discussing at the last= meeting. As you say below, the list of all the captures would be distinct= from the mutual exclusion sets. I do understand Roni's objections from his last posting, so thank you Roni = for clarifying that. Personally, I am only mildly in favor of using mutually exclusive sets inst= ead of simultaneous sets. So it is okay with me if the group decides not t= o make the change. But a few other people also expressed preference for mu= tually exclusive, so maybe there should be more discussion. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, March 23, 2012 11:22 AM > To: clue@ietf.org > Subject: Re: [clue] Simultaneous set, or mutually exclusive set? > > Mark, Roni, > > It seems clear to me that the two of you are not understanding one anothe= r. > > Looking at Mark's original comparison of simultaneous sets vs. mutually > exclusive sets, I think one thing is missing from the proposal for mutual= ly > exclusive sets: > > In addition to listing which captures are mutually exclusive, there is a = need to > enumerate all the captures that are being advertised. Something > like: > > Captures: {V1, V2, V3, V4, V5, V6} > Mutual Exclusion: {VC1, VC2}, {VC3, VC4}, {VC5, VC6} > > Of course there can be a number of ways to optimize the representation of > this. For instance, all the captures listed in mutual exclusion sets can = be > assumed to be advertised, so perhaps it is only necessary to additionally > advertise those that aren't so listed. In your case all have been listed = in > mutual exclusion sets so no others need be listed. > But that need not always be the case. This would be especially obvious wh= en > there are no mutual exclusion rules. > > Thanks, > Paul (as individual) > > On 3/23/12 10:21 AM, Duckworth, Mark wrote: > > Hi Roni, > > > > It sounds like you are making an alternative proposal of your own, > > because a mutually exclusive set of {VC0} has no meaning in my proposal= . > > > > My view is that a consumer that wants to make an easy simple choice > > should select a capture scene entry and ask for all or part of it. The > > simultaneous sets or mutually exclusive sets are irrelevant if the > > consumer chooses from a capture scene entry. > > > > Mark > > > > *From:*Roni even [mailto:Even.roni@huawei.com] > > *Sent:* Friday, March 23, 2012 10:11 AM > > *To:* Duckworth, Mark; clue@ietf.org > > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Mark, > > > > You need the whole set of relations even {vc0} to have the complete > > set of dependencies > > > > The simultaneous set is 2 lines wile the mutual exclusive is 3 or 5 > > lines depending on how you want to present it > > > > My claim is that in the general case you cannot have an optimal > > solution using only "OR" or only "AND" you may need a mixture so > > selecting only one of them does not provide an optimal solution > > > > My view is that by using simultaneous set it is easier for a consumer > > to select a set it wants to receive since he only need to select a > > line and ask for all of it or part of it. For the mutual exclusive he > > will need first to build the simultaneous sets > > > > Roni > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni > > even [Even.roni@huawei.com] > > *Sent:* Friday, March 23, 2012 15:38 > > *To:* Duckworth, Mark; clue@ietf.org > > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > > > Mark, > > > > the discussion is about the example in the framework draft and how it > > should be specified using only mutual exclusive set > > > > Simultaneous set > > > > {VC0, VC1, VC2, VC3, VC4, VC6} > > > > {VC0, VC2, VC5, VC6} > > > > Will have as exclusive set > > > > {VC0} > > > > {VC1,VC5} > > > > {VC2} > > > > {VC3,VC5} > > > > {VC4,VC5} > > > > {VC6} > > > > Roni > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > > Duckworth, Mark [Mark.Duckworth@polycom.com] > > *Sent:* Friday, March 23, 2012 15:25 > > *To:* clue@ietf.org > > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > > > Hi Roni, > > > > Maybe I'm not being clear about my suggestion. > > > > With my mutually exclusive set suggestion, for this example, the > > mutually exclusive sets are: > > > > {VC1,VC5} - meaning VC1 and VC5 cannot be used at same time > > > > {VC3,VC5} - meaning VC3 and VC5 cannot be used at same time > > > > {VC4,VC5} - meaning VC4 and VC5 cannot be used at same time > > > > I don't know what you mean by adding something like {VC0} into the > > list of mutually exclusive sets. In my proposal, that has no meaning. > > > > Mark > > > > *From:*Roni even [mailto:Even.roni@huawei.com] > > *Sent:* Friday, March 23, 2012 1:31 AM > > *To:* Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org > > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Espen, > > > > This is not true!!!. using mark suggesting it will look like > > > > {VC0} > > > > {VC1,VC5} > > > > {VC2} > > > > {VC3,VC5} > > > > {VC4,VC5} > > > > {VC6} > > > > If you want it to look like > > > > {VC5, [VC1, VC3, VC4] } > > > > you will need to define something which is not only mutual exclusive. > > But also simultaneous at the same time since [vc,vc3,vc4] are > > simultaneous in this case > > > > Roni > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*Espen Berger (espeberg) [espeberg@cisco.com] > > *Sent:* Thursday, March 22, 2012 22:29 > > *To:* Roni even; Duckworth, Mark; clue@ietf.org > > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Roni, in my example I only ment to express that VC5 cannot be sent at > > the same time as VC1, VC3 or VC4. I did not intend [] to indicate > > simultaneous. > > > > So Marks suggested notation is compact, easy to understand and cover > > the example from the framework. > > > > -Espen > > > > *From:*Roni even [mailto:Even.roni@huawei.com] > > *Sent:* 22. mars 2012 20:59 > > *To:* Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org > > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Espen, > > > > I am confused now since for the example from the framework you > > suggested a mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, > > VC4] } the ones in the [] are simultaneous while the one in {} are mutu= al > exclusive. > > > > Roni > > > > ---------------------------------------------------------------------- > > -- > > > > *From:*clue-bounces@ietf.org > > [clue-bounces@ietf.org] on behalf of Espen Berger (espeberg) > > [espeberg@cisco.com] > > *Sent:* Thursday, March 22, 2012 18:20 > > *To:* Duckworth, Mark; clue@ietf.org > > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > > > No Boolean algebra is needed. I do not think we need that complexity > > in what we want to describe. > > > > I agree with marks suggestion to write it up like this: > > > > {VC1,VC5} > > > > {VC3,VC5} > > > > {VC4,VC5} > > > > Cheers > > > > -Espen > > > > *From:*clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mark > > *Sent:* 22. mars 2012 16:19 > > *To:* clue@ietf.org > > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > > > I would rather not complicate this with Boolean algebra. > > > > Mark > > > > *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > > *Sent:* Thursday, March 22, 2012 11:08 AM > > *To:* 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org > > > > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Hi Espen, > > > > This is different since now you have a combination of simultaneous set > > and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} > > > > This is not what Mark was proposing and this expands the > > representation to be more in line with Boolean algebra in which case > > we will need to define the syntax for (AND, OR, XOR,..) > > > > This will allow having Mark example as > > > > {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} > > > > The selection becomes one from each OR and all or some of the AND. > > > > Do we want to go to this syntax? > > > > Roni > > > > *From:*Espen Berger (espeberg) [mailto:espeberg@cisco.com] > > *Sent:* Thursday, March 22, 2012 4:17 PM > > *To:* Roni Even; Duckworth, Mark; clue@ietf.org > > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > I think that mutual exclusive sets can be used to model the example > > 11.1 in the framework document. A snippet from the document < > cannot be used at the same time as VC1 or VC3 or VC4.>> > > > > In the example the main thing to model is that a selection of VC5 has > > side effects and basically exclude some of the other alternatives > > > > *VC5 exclude VC1; VC1 and VC5 is the same physical camera so they > > cannot be sent at the same time. > > > > *VC5 excludes VC3; Since the middle camera does not capture the middle > > segment anymore, and segment switching into middle segment is not > > possible anymore > > > > *VC5 excludes VC4; A composed view cannot be rendered since VC1 does > > not capture the middle segment anymore. > > > > In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 > > which could be written as > > > > {VC5, [VC1, VC3, VC4] } // or some other nice syntax > > > > Cheers > > > > -Espen > > > > *From:*clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even > > *Sent:* 22. mars 2012 09:13 > > *To:* 'Duckworth, Mark'; clue@ietf.org > > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > > > Hi Mark, > > > > This is a good _example_ for shorter Mutual exclusive set but taking > > the example from the framework draft > > > > {VC0, VC1, VC2, VC3, VC4, VC6} > > > > {VC0, VC2, VC5, VC6} > > > > Will have as exclusive set > > > > {VC0} > > > > {VC1,VC5} > > > > {VC2} > > > > {VC3,VC5} > > > > {VC4,VC5} > > > > {VC6} > > > > As far as I remember my Boolean algebra the optimized number of > > entries may be different if we limit ourselves to use either > > representations. So if we really want to optimize the number of > > entries we can use Boolean equations to represent the relations. > > Otherwise it does not matter which method you choose and we should > look at how we use this information. > > > > The important issue in not only the representation but it is how to do > > does the selection. > > > > In the case of simultaneous set you choose a line or part of it, very > > simple!!! > > > > In the case of mutually exclusive set it is not easy since you cannot > > just select one MC from each row (not in your example which is one > > case but in the example from the framework draft), you will need to > > combine them to Mutual exclusive sets. > > > > This is what I claimed in the previous email you sent, and why I > > prefer simultaneous set. I strongly object to using mutually exclusive > > sets unless you can explain how you can have an easy select criteria. > > > > The capture sets are not providing a full picture but just a subset of > > the full options that are recommended by the provider. > > > > Roni > > > > *From:*clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] *On Behalf Of *Duckworth, Mark > > *Sent:* Tuesday, March 20, 2012 12:05 AM > > *To:* clue@ietf.org > > *Subject:* [clue] Simultaneous set, or mutually exclusive set? > > > > This is a follow on to the email thread with subject 'propose > > "mutually exclusive" attribute to replace simutaneous sets'. It seemed > > like that thread didn't have any agreement. So I'll suggest a simpler > > change to see what you think. This is motivated by a discussion at the > > interim meeting where I thought a few people were in favor of this. > > > > Instead of conveying the information about which media captures can be > > used at the same time with "simultaneous sets", do it instead with > > "mutually exclusive sets". The purpose is to have a more concise way > > to indicate which media captures cannot be used at the same time, > > which we believe scales better than the simultaneous set idea when > > there are multiple mutually exclusive constraints. > > > > Here is an example of the difference. Suppose a provider is > > advertising six video captures. The provider wants to say that VC1 and > > VC2 can't be used at the same time. And VC3 and VC4 can't be used at th= e > same time. > > And VC5 and VC6 can't be used at the same time. > > > > In simultaneous sets it would be expressed like this: > > > > {VC1, VC3, VC5} > > > > {VC1, VC4, VC5} > > > > {VC1, VC3, VC6} > > > > {VC1, VC4, VC6} > > > > {VC2, VC3, VC5} > > > > {VC2, VC4, VC5} > > > > {VC2, VC3, VC6} > > > > {VC2, VC4, VC6} > > > > With mutually exclusive sets, it would be expressed like this: > > > > {VC1, VC2} > > > > {VC3, VC4} > > > > {VC5, VC6} > > > > Does anybody see any advantage or disadvantage to this? > > > > Mark > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mphmmr@gmail.com Fri Mar 23 11:56:29 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6168721F861F for ; Fri, 23 Mar 2012 11:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiHc1jLFbeiH for ; Fri, 23 Mar 2012 11:56:25 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57FD721F85F4 for ; Fri, 23 Mar 2012 11:56:24 -0700 (PDT) Received: by lagj5 with SMTP id j5so2995445lag.31 for ; Fri, 23 Mar 2012 11:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IldhzaFEf/H4+FzC/ZjQKG5BqTjgJQcfjCRh8YpnKRc=; b=wgN8CjZemuS+ZRoMlg/s/kvuQZbTNy8CBIRM7e8rTyAlzwE3NEiWyOZH9inzxuSPTX Qvo2VCG6iQ3yUsnJF+4hKTWQ7yeOFN3HOam4xHwpWL5paIPDREiF8WUBgfcm997jmiAF /NhrAomd25WbIo6KsIMkGwfaLrz61+T8e5Dd5Xp46GdJk0ZyD8Np//cniit9xY0NiPnT vJyupinRqRZHqm40Gl9V5JWznfed9nH8QO1014j4IJXkz1SiIey2JIdjdF4DgTxFiXqE Du3YH8JKI5JX7iLf2zweZvQjUcrKRO2P1i9FJnuZSAgYS+51AY7XbzI9q4t9Dv6eDdfc tpyw== MIME-Version: 1.0 Received: by 10.112.45.106 with SMTP id l10mr1550709lbm.45.1332528983218; Fri, 23 Mar 2012 11:56:23 -0700 (PDT) Received: by 10.112.76.196 with HTTP; Fri, 23 Mar 2012 11:56:23 -0700 (PDT) In-Reply-To: References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> <4f6adf4a.c652b40a.5727.ffff935d@mx.google.com> <92DF9533227FC14F946C7321074B8C9E0109C9CE@XMB-AMS-214.cisco.com> <4f6b40a3.e869b40a.05c4.44e1@mx.google.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60A38@CRPMBOXPRD01.polycom.com> <92DF9533227FC14F946C7321074B8C9E0109CA19@XMB-AMS-214.cisco.com> <92DF9533227FC14F946C7321074B8C9E0109CA59@XMB-AMS-214.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A6102FCB60E21@CRPMBOXPRD01.polycom.com> Date: Fri, 23 Mar 2012 14:56:23 -0400 Message-ID: From: Michael Hammer To: Roni even Content-Type: multipart/alternative; boundary=bcaec554057ab298ef04bbed94a7 Cc: "clue@ietf.org" Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 18:56:29 -0000 --bcaec554057ab298ef04bbed94a7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So this is the NOT AND (NAND) solution. Could NOT OR (NOR) solution be far behind? :) Mike On Fri, Mar 23, 2012 at 10:11 AM, Roni even wrote: > Mark, > > You need the whole set of relations even {vc0} to have the complete set o= f > dependencies > > The simultaneous set is 2 lines wile the mutual exclusive is 3 or 5 lines > depending on how you want to present it > > > > My claim is that in the general case you cannot have an optimal solution > using only "OR" or only "AND" you may need a mixture so selecting only on= e > of them does not provide an optimal solution > > > > My view is that by using simultaneous set it is easier for a consumer to > select a set it wants to receive since he only need to select a line and > ask for all of it or part of it. For the mutual exclusive he will need > first to build the simultaneous sets > > > > Roni > ------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Roni > even [Even.roni@huawei.com] > *Sent:* Friday, March 23, 2012 15:38 > *To:* Duckworth, Mark; clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > Mark, > > the discussion is about the example in the framework draft and how it > should be specified using only mutual exclusive set > > > > Simultaneous set > > {VC0, VC1, VC2, VC3, VC4, VC6} > > {VC0, VC2, VC5, VC6} > > Will have as exclusive set > > {VC0} > > {VC1,VC5} > > {VC2} > > {VC3,VC5} > > {VC4,VC5} > > {VC6} > > Roni > ------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com] > *Sent:* Friday, March 23, 2012 15:25 > *To:* clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > Hi Roni, > > Maybe I=92m not being clear about my suggestion. > > With my mutually exclusive set suggestion, for this example, the mutually > exclusive sets are: > > {VC1,VC5} =96 meaning VC1 and VC5 cannot be used at same time > > {VC3,VC5} =96 meaning VC3 and VC5 cannot be used at same time > > {VC4,VC5} =96 meaning VC4 and VC5 cannot be used at same time > > > > I don=92t know what you mean by adding something like {VC0} into the list= of > mutually exclusive sets. In my proposal, that has no meaning. > > > > Mark > > > > *From:* Roni even [mailto:Even.roni@huawei.com] > *Sent:* Friday, March 23, 2012 1:31 AM > *To:* Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Espen, > > This is not true!!!. using mark suggesting it will look like > > > > {VC0} > > {VC1,VC5} > > {VC2} > > {VC3,VC5} > > {VC4,VC5} > > {VC6} > > > > If you want it to look like > > > > > > {VC5, [VC1, VC3, VC4] } > > > > you will need to define something which is not only mutual exclusive. But > also simultaneous at the same time since [vc,vc3,vc4] are simultaneous in > this case > > > > Roni > > > ------------------------------ > > *From:* Espen Berger (espeberg) [espeberg@cisco.com] > *Sent:* Thursday, March 22, 2012 22:29 > *To:* Roni even; Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > Roni, in my example I only ment to express that VC5 cannot be sent at the > same time as VC1, VC3 or VC4. I did not intend [] to indicate simultaneou= s. > > > > > So Marks suggested notation is compact, easy to understand and cover the > example from the framework. > > > > -Espen > > > > > > *From:* Roni even [mailto:Even.roni@huawei.com] > *Sent:* 22. mars 2012 20:59 > *To:* Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Espen, > > I am confused now since for the example from the framework you suggested = a > mix of simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones > in the [] are simultaneous while the one in {} are mutual exclusive. > > > > Roni > ------------------------------ > > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Espen > Berger (espeberg) [espeberg@cisco.com] > *Sent:* Thursday, March 22, 2012 18:20 > *To:* Duckworth, Mark; clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > No Boolean algebra is needed. I do not think we need that complexity in > what we want to describe. > > > > I agree with marks suggestion to write it up like this: > > {VC1,VC5} > > {VC3,VC5} > > {VC4,VC5} > > > > Cheers > > > > -Espen > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Duckworth, Mark > *Sent:* 22. mars 2012 16:19 > *To:* clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > > > I would rather not complicate this with Boolean algebra. > > Mark > > > > *From:* Roni Even [mailto:ron.even.tlv@gmail.com = ] > > *Sent:* Thursday, March 22, 2012 11:08 AM > *To:* 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > Hi Espen, > > This is different since now you have a combination of simultaneous set > and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} > > This is not what Mark was proposing and this expands the representation t= o > be more in line with Boolean algebra in which case we will need to define > the syntax for (AND, OR, XOR,..) > > This will allow having Mark example as > > {VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 OR VC6} > > > > The selection becomes one from each OR and all or some of the AND. > > > > Do we want to go to this syntax? > > > > > > Roni > > > > > > *From:* Espen Berger (espeberg) [mailto:espeberg@cisco.com] > > *Sent:* Thursday, March 22, 2012 4:17 PM > *To:* Roni Even; Duckworth, Mark; clue@ietf.org > *Subject:* RE: [clue] Simultaneous set, or mutually exclusive set? > > > > I think that mutual exclusive sets can be used to model the example 11.1 > in the framework document. A snippet from the document < used at the same time as VC1 or VC3 or VC4.>> > > > > In the example the main thing to model is that a selection of VC5 has sid= e > effects and basically exclude some of the other alternatives > > =B7 VC5 exclude VC1; VC1 and VC5 is the same physical camera so > they cannot be sent at the same time. > > =B7 VC5 excludes VC3; Since the middle camera does not capture th= e > middle segment anymore, and segment switching into middle segment is not > possible anymore > > =B7 VC5 excludes VC4; A composed view cannot be rendered since VC= 1 > does not capture the middle segment anymore. > > > > In other terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 > which could be written as > > {VC5, [VC1, VC3, VC4] } // or some other nice syntax > > > > Cheers > > > > -Espen > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Roni Even > *Sent:* 22. mars 2012 09:13 > *To:* 'Duckworth, Mark'; clue@ietf.org > *Subject:* Re: [clue] Simultaneous set, or mutually exclusive set? > > > > Hi Mark, > > This is a good *example* for shorter Mutual exclusive set but taking the > example from the framework draft > > > > {VC0, VC1, VC2, VC3, VC4, VC6} > > > > {VC0, VC2, VC5, VC6} > > > > Will have as exclusive set > > > > {VC0} > > {VC1,VC5} > > {VC2} > > {VC3,VC5} > > {VC4,VC5} > > {VC6} > > > > As far as I remember my Boolean algebra the optimized number of entries > may be different if we limit ourselves to use either representations. So = if > we really want to optimize the number of entries we can use Boolean > equations to represent the relations. Otherwise it does not matter which > method you choose and we should look at how we use this information. > > The important issue in not only the representation but it is how to do > does the selection. > > > > In the case of simultaneous set you choose a line or part of it, very > simple!!! > > > > In the case of mutually exclusive set it is not easy since you cannot jus= t > select one MC from each row (not in your example which is one case but in > the example from the framework draft), you will need to combine them to > Mutual exclusive sets. > > > > This is what I claimed in the previous email you sent, and why I prefer > simultaneous set. I strongly object to using mutually exclusive sets unle= ss > you can explain how you can have an easy select criteria. > > The capture sets are not providing a full picture but just a subset of th= e > full options that are recommended by the provider. > > > > Roni > > > > > > > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] > *On Behalf Of *Duckworth, Mark > *Sent:* Tuesday, March 20, 2012 12:05 AM > *To:* clue@ietf.org > *Subject:* [clue] Simultaneous set, or mutually exclusive set? > > > > This is a follow on to the email thread with subject =91propose "mutually > exclusive" attribute to replace simutaneous sets=92. It seemed like that > thread didn=92t have any agreement. So I=92ll suggest a simpler change t= o see > what you think. This is motivated by a discussion at the interim meeting > where I thought a few people were in favor of this. > > > > Instead of conveying the information about which media captures can be > used at the same time with =93simultaneous sets=94, do it instead with > =93mutually exclusive sets=94. The purpose is to have a more concise way= to > indicate which media captures cannot be used at the same time, which we > believe scales better than the simultaneous set idea when there are > multiple mutually exclusive constraints. > > > > Here is an example of the difference. Suppose a provider is advertising > six video captures. The provider wants to say that VC1 and VC2 can=92t b= e > used at the same time. And VC3 and VC4 can=92t be used at the same time. > And VC5 and VC6 can=92t be used at the same time. > > > > In simultaneous sets it would be expressed like this: > > {VC1, VC3, VC5} > > {VC1, VC4, VC5} > > {VC1, VC3, VC6} > > {VC1, VC4, VC6} > > {VC2, VC3, VC5} > > {VC2, VC4, VC5} > > {VC2, VC3, VC6} > > {VC2, VC4, VC6} > > > > With mutually exclusive sets, it would be expressed like this: > > {VC1, VC2} > > {VC3, VC4} > > {VC5, VC6} > > > > Does anybody see any advantage or disadvantage to this? > > > > Mark > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec554057ab298ef04bbed94a7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So this is the NOT AND (NAND) solution.

Could =A0NOT OR = (NOR) solution be far behind? =A0:)

Mike


On Fri, Mar 23, 2012 at 10:11 AM, Roni = even <Even.ron= i@huawei.com> wrote:

Mark,

You need the whole set of relations even {vc0} to have the complete set = of dependencies

The=A0simultaneous set is 2 lines wile the mutual exclusive is 3 = or 5 lines depending on how you want to present it

=A0

My claim is that in the=A0general case you=A0cannot have a= n optimal solution using only "OR" or only "AND" you ma= y need a mixture so selecting only one of them does not=A0provide an= optimal solution

=A0

My view is=A0that=A0by using=A0simultaneous set it = is easier for a consumer to select a set it wants to=A0receive=A0sin= ce he only need to select a line and ask for all of it or part of it= . For the mutual exclusive he will need first to build the=A0simultaneous sets

=A0

Roni

Fro= m: clue-boun= ces@ietf.org [clue-bounces@ietf.org] on behalf of Roni even [Even.roni@huawei.com]
Sent: Friday, March 23, 2012 15:38
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

Mark,

the discussion is about the example in the=A0framework=A0draft= and how it should be specified using only mutual exclusive set

=A0

Simultaneous set

{VC0, VC1, VC2, VC3, VC4, VC6}<= /span>

{VC0, VC2, VC5, VC6}

Will have as exclusive set

{VC0}

{VC1,VC5}

{VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}

Roni

Fro= m: clue-boun= ces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com<= /a>]
Sent: Friday, March 23, 2012 15:25
To: clue@ietf.org=
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

Hi Roni,

Maybe I=92m not being = clear about my suggestion.

With my mutually exclu= sive set suggestion, for this example, the mutually exclusive sets are:

{VC1,VC5} =96 meaning = VC1 and VC5 cannot be used at same time

{VC3,VC5} =96 meaning = VC3 and VC5 cannot be used at same time

{VC4,VC5} =96 meaning = VC4 and VC5 cannot be used at same time

=A0

I don=92t know what yo= u mean by adding something like {VC0} into the list of mutually exclusive s= ets.=A0 In my proposal, that has no meaning.

=A0

Mark

=A0

From: Roni even [mailto:Even.roni@huawei.co= m]
Sent: Friday, March 23, 2012 1:31 AM
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

=A0

Espen,

This is not true!!!.=A0 using mark suggesting it wi= ll look like

=A0

{VC0}

{VC1,VC5}

{VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}

=A0

If you want it to look like=

=A0

=A0

{VC5, [VC1, V= C3, VC4] }

=A0

you will need= to define something=A0which is not only mutual exclusive. But also=A0simul= taneous at the same time since [vc,vc3,vc4] are=A0simultaneous in this case

=A0

Roni

=A0

From: Espen Berger (espeberg) [espeberg@cisco.com]
Sent: Thursday, March 22, 2012 22:29
To: Roni even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

Roni, i= n my example I only ment to express that VC5 cannot be sent at the same tim= e as VC1, VC3 or VC4. I did not intend [] to indicate simultaneous. =A0

=A0

So Mark= s suggested notation is compact, easy to understand and cover the example f= rom the framework.

=A0

-Espen =

=A0

=A0

From: Roni even [mailto:Even.roni@huawei.co= m]
Sent: 22. mars 2012 20:59
To: Espen Berger (espeberg); Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

=A0

Espen,

I am confused now since for the example from the fr= amework you suggested a mix of=A0simultaneous and mutual exclusive {VC5, [VC1, VC3, VC4] } the ones = in the [] are=A0simultaneous while the one in {} are mutual exclusive.

=A0

Roni

From: clue-bounces@iet= f.org [clue-= bounces@ietf.org] on behalf of Espen Berger (espeberg) [espeberg@cisco.com]
Sent: Thursday, March 22, 2012 18:20
To: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

No Bool= ean algebra is needed. I do not think we need that complexity in what we wa= nt to describe.

=A0

I agree= with marks suggestion to write it up like this:

{VC1,VC5}

{VC3,VC5}

{VC4,VC5}

=A0

Cheers =

=A0

-Espen =

=A0

=A0

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: 22. mars 2012 16:19
To: clue@ietf.org=
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

=A0

I would rather not com= plicate this with Boolean algebra.=

Mark

=A0

From: Roni Even [mailto:ron.even.tlv@gm= ail.com]
Sent: Thursday, March 22, 2012 11:08 AM
To: 'Espen Berger (espeberg)'; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

=A0

Hi Espen,

This is different since now you have a c= ombination =A0of simultaneous set =A0and mutual exclusive. Like {VC5 OR (VC1 AND VC3 AND VC4)} =A0=A0

This is not what Mark was proposing and = this expands the representation to be more in line with Boolean algebra in = which case we will need to define the syntax for (AND, OR, XOR,..)

This will allow having Mark example as

{VC1 OR VC2} AND {VC3 OR VC4} AND {VC5 O= R VC6}

=A0

The selection becomes one from each OR a= nd all or some of the AND.

=A0

Do we want to go to this syntax?<= span style lang=3D"EN-GB">

=A0

=A0

Roni

=A0

=A0

From: Espen Berger (espebe= rg) [mailto:espeber= g@cisco.com]
Sent: Thursday, March 22, 2012 4:17 PM
To: Roni Even; Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] Simultaneous set, or mutually exclusive set?

=A0

I think= that mutual exclusive sets can be used to model the example 11.1 in the fr= amework document.=A0 A snippet from the document <<VC5 cannot be used= at the same time as VC1 or VC3 or =A0VC4.>>

=A0

In the = example the main thing to model is that a selection of VC5 has side effects= and basically exclude some of the other alternatives

=B7=A0=A0=A0=A0=A0=A0=A0=A0 =A0VC5 exclude VC1; VC1= and VC5 is the same physical camera so they cannot be sent at the same tim= e.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 VC5 excludes VC3; Since= the middle camera does not capture the middle segment anymore, and segment= switching into middle segment is not possible anymore

=B7=A0=A0=A0=A0=A0=A0=A0=A0 VC5 excludes VC4; A com= posed view cannot be rendered since VC1 does not capture the middle segment= anymore.

=A0

In othe= r terms; Selecting VC5 excludes usage of capture VC1, VC3, VC4 which could = be written as

{VC5, [= VC1, VC3, VC4] } =A0=A0// or some other nice syntax

=A0

Cheers =

=A0

-Espen= =A0

=A0

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: 22. mars 2012 09:13
To: 'Duckworth, Mark'; clue@ietf.org
Subject: Re: [clue] Simultaneous set, or mutually exclusive set?

=A0

Hi Mark,

This is a good exam= ple for shorter Mutual exclusive set but taking the example from the fr= amework draft

=A0

{VC0, VC1, VC2, VC3, VC4, VC6}<= /span>

=A0

=A0=A0=A0=A0=A0 {VC0, VC2, VC5, VC6}

=A0

Will have as exclusive set

=A0

{VC0}

{VC1,VC5}

{VC2}

{VC3,VC5}

{VC4,VC5}

{VC6}

=A0

As far as I remember my Boolean algebra the optimized number of e= ntries may be different if we limit ourselves to use either representations= . So if we really want to optimize the number of entries we can use Boolean equations to rep= resent the relations. Otherwise it does not matter which method you choose = and we should look at how we use this information.

The important issue in not only the representation but it =A0is h= ow to do does the selection.

=A0

In the case of simultaneous set you choose a line or part of it, = very simple!!!

=A0

In the case of mutually exclusive set it is not easy since you ca= nnot just select one MC from each row (not in your example which is one cas= e but in the example from the framework draft), you will need to combine them to Mutual= exclusive sets.

=A0

This is what I claimed in the previous email you sent, and why I = prefer simultaneous set. I strongly object to using mutually exclusive sets= unless you can explain how you can have an easy select criteria.

The capture sets are not providing a full picture but just a subs= et of the full options that are recommended by the provider.

=A0

Roni

=A0

=A0

=A0

From: clue-bounces@iet= f.org [mailt= o:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 AM
To: clue@ietf.org=
Subject: [clue] Simultaneous set, or mutually exclusive set?<= span style lang=3D"EN-GB">

=A0

This is a follow on to the email thread = with subject =91propose "mutually exclusive" attribute to replace= simutaneous sets=92.=A0 It seemed like that thread didn=92t have any agree= ment.=A0 So I=92ll suggest a simpler change to see what you think.=A0 This is motivated by a discussion at the interim= meeting where I thought a few people were in favor of this.

=A0

Instead of conveying the information abo= ut which media captures can be used at the same time with =93simultaneous s= ets=94, do it instead with =93mutually exclusive sets=94.=A0 The purpose is= to have a more concise way to indicate which media captures cannot be used at the same time, which we be= lieve scales better than the simultaneous set idea when there are multiple = mutually exclusive constraints.

=A0

Here is an example of the difference.=A0= Suppose a provider is advertising six video captures.=A0 The provider want= s to say that VC1 and VC2 can=92t be used at the same time.=A0 And VC3 and = VC4 can=92t be used at the same time.=A0 And VC5 and VC6 can=92t be used at the same time.

=A0

In simultaneous sets i= t would be expressed like this:

{VC1, VC3, VC5}=

{VC1, VC4, VC5}=

{VC1, VC3, VC6}=

{VC1, VC4, VC6}=

{VC2, VC3, VC5}=

{VC2, VC4, VC5}=

{VC2, VC3, VC6}=

{VC2, VC4, VC6}=

=A0

With mutually exclusive sets, it would b= e expressed like this:

{VC1, VC2}

{VC3, VC4}

{VC5, VC6}

=A0

Does anybody see any advantage or disadv= antage to this?

=A0

Mark


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


--bcaec554057ab298ef04bbed94a7-- From ron.even.tlv@gmail.com Sat Mar 24 14:01:53 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C57C21F8582 for ; Sat, 24 Mar 2012 14:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDZp7PqNrYtR for ; Sat, 24 Mar 2012 14:01:51 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52EE021F8581 for ; Sat, 24 Mar 2012 14:01:51 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so4134604pbb.31 for ; Sat, 24 Mar 2012 14:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:content-language:thread-index; bh=1b/ezsRxr23Cqa86utvJrgqfsyACq/IfvK2LO7VyCvQ=; b=z/Q1/Pp52ANafxTEk5K+3/XQzwj8afxkRpJiS9ZUwVx3gmeyGpd9paklfMJc6sjyeg V4oJdIadfb4n9Wd4w9WyeL32g9fWGNz6dQxmIBQaYKHj4leMEDs1yh454C/hXyutijQf y66ra07lRdbi3PTiVWgdrcCo9BeN2eOwlYLBwcB/pmGRiZAx3mlQKglm3x+wkMw75N3t WlP1YNUKqL4fXP4CRwU54Zn1bQfDJLyA5GLP+wser+ObMlL3Sw7qXk/Z93QX5Z6gFR11 sqwoo1F1ek9v9lS9w+YvI95yUr8hF8pO68Mrgw7RsUji/Jj8gzlOvRqJwmk6cCfJTQ+n m4qw== Received: by 10.68.203.4 with SMTP id km4mr40187929pbc.53.1332622911148; Sat, 24 Mar 2012 14:01:51 -0700 (PDT) Received: from windows8d787f9 (dhcp-4432.meeting.ietf.org. [130.129.68.50]) by mx.google.com with ESMTPS id v1sm2525139pbk.10.2012.03.24.14.01.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 14:01:49 -0700 (PDT) From: "Roni Even" To: "'Duckworth, Mark'" , References: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCA3092A@CRPMBOXPRD01.polycom.com> Date: Sat, 24 Mar 2012 23:00:36 +0200 Message-ID: <4f6e363d.4128440a.5f86.ffff81de@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CD0A11.F2314750" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: Ac0GGrFzzL+FjTFfQ7e1ZIuYIrv8WgD5JISw Subject: Re: [clue] Simultaneous set, or mutually exclusive set? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 21:01:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01CD0A11.F2314750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mark, Just an example to prove my point about the using only OR for description will not necessarily create the shortest list for those who still believe the using Mutual Exclusive will always create a shorter description. Supposes VC1 cannot be used with VC2 or VC3 or VC4 or VC5 or VC6 Simultaneous {VC1} {VC2,VC3,VC4,VC5,VC6} Mutual exclusive {VC1,VC2} {VC1,VC3} {VC1, VC4} {VC1,VC5} {VC1,VC6} Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Tuesday, March 20, 2012 12:05 AM To: clue@ietf.org Subject: [clue] Simultaneous set, or mutually exclusive set? This is a follow on to the email thread with subject 'propose "mutually exclusive" attribute to replace simutaneous sets'. It seemed like that thread didn't have any agreement. So I'll suggest a simpler change to see what you think. This is motivated by a discussion at the interim meeting where I thought a few people were in favor of this. Instead of conveying the information about which media captures can be used at the same time with "simultaneous sets", do it instead with "mutually exclusive sets". The purpose is to have a more concise way to indicate which media captures cannot be used at the same time, which we believe scales better than the simultaneous set idea when there are multiple mutually exclusive constraints. Here is an example of the difference. Suppose a provider is advertising six video captures. The provider wants to say that VC1 and VC2 can't be used at the same time. And VC3 and VC4 can't be used at the same time. And VC5 and VC6 can't be used at the same time. In simultaneous sets it would be expressed like this: {VC1, VC3, VC5} {VC1, VC4, VC5} {VC1, VC3, VC6} {VC1, VC4, VC6} {VC2, VC3, VC5} {VC2, VC4, VC5} {VC2, VC3, VC6} {VC2, VC4, VC6} With mutually exclusive sets, it would be expressed like this: {VC1, VC2} {VC3, VC4} {VC5, VC6} Does anybody see any advantage or disadvantage to this? Mark ------=_NextPart_000_001F_01CD0A11.F2314750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mark,

Just an example to prove = my point about the using only OR  for description will not = necessarily create the shortest list  for those who still believe = the using Mutual Exclusive will always create a shorter = description.

 

Supposes VC1 cannot be = used with VC2 or VC3 or VC4 or VC5 or VC6

 

Simultaneous

 

{VC1}

{VC2,VC3,VC4,VC5,VC6}

 

Mutual = exclusive

 

{VC1,VC2}

{VC1,VC3}

{VC1, = VC4}

{VC1,VC5}

{VC1,VC6}

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Tuesday, March 20, 2012 12:05 = AM
To: clue@ietf.org
Subject: [clue] Simultaneous = set, or mutually exclusive set?

 

This is a = follow on to the email thread with subject ‘propose "mutually = exclusive" attribute to replace simutaneous sets’.  It = seemed like that thread didn’t have any agreement.  So = I’ll suggest a simpler change to see what you think.  This is = motivated by a discussion at the interim meeting where I thought a few = people were in favor of this.

 

Instead of = conveying the information about which media captures can be used at the = same time with “simultaneous sets”, do it instead with = “mutually exclusive sets”.  The purpose is to have a = more concise way to indicate which media captures cannot be used at the = same time, which we believe scales better than the simultaneous set idea = when there are multiple mutually exclusive constraints.

 

Here is an = example of the difference.  Suppose a provider is advertising six = video captures.  The provider wants to say that VC1 and VC2 = can’t be used at the same time.  And VC3 and VC4 can’t = be used at the same time.  And VC5 and VC6 can’t be used at = the same time.

 

In simultaneous sets it would be expressed like = this:

{VC1, VC3, VC5}

{VC1, VC4, = VC5}

{VC1, VC3, VC6}

{VC1, VC4, = VC6}

{VC2, VC3, VC5}

{VC2, VC4, = VC5}

{VC2, VC3, VC6}

{VC2, VC4, = VC6}

 

With mutually exclusive sets, it would be expressed = like this:

{VC1, = VC2}

{VC3, VC4}

{VC5, VC6}

 

Does anybody = see any advantage or disadvantage to this?

 

Mark

------=_NextPart_000_001F_01CD0A11.F2314750-- From stephen.botzko@gmail.com Mon Mar 26 05:47:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3CB21F851E for ; Mon, 26 Mar 2012 05:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k1Qfbk2q0+C for ; Mon, 26 Mar 2012 05:47:35 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F104321F84AA for ; Mon, 26 Mar 2012 05:47:31 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4140581ghb.31 for ; Mon, 26 Mar 2012 05:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QVOlRllSfC9CRU5QQmDqEgtrscSvRXMgt0e9CIg5Q2Q=; b=rf1xngGmQ/0Lgn6v0ZEXWO4esE5s4xatPgjKxgdjXUYHn1vJDJN1wVvSbPWAUV3zfa 1qc0l0PeDrDDhrKsVnOdlIVKQExZGP08pXmG+VWbHqJPQsGX6cLzyZ5gRF8Alf/2ciED NW+qKOw8fhSrDinO5La801kqP3TUoUoaj7sug+hs+hFE3f6mnUI+xBXvli5CDKBU26LT 59LJnC0INcmRIpqbVHZzHzcVWjdd/6DhwiXL4P7h+29WIOtyhaf9hQ1BIbuXuapz4/ma 69gbUCxnN27c9p3+FRy62TdnlpuCcvGiUxQWBM1pe8jN0qIMfUoab42pfeXyN5ja35AF TXGA== MIME-Version: 1.0 Received: by 10.68.229.33 with SMTP id sn1mr53701800pbc.59.1332766051167; Mon, 26 Mar 2012 05:47:31 -0700 (PDT) Received: by 10.68.32.37 with HTTP; Mon, 26 Mar 2012 05:47:31 -0700 (PDT) In-Reply-To: <20120321202355.GJ79816@verdi> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> Date: Mon, 26 Mar 2012 14:47:31 +0200 Message-ID: From: Stephen Botzko To: John Leslie Content-Type: multipart/alternative; boundary=047d7b1601bb0c6e4f04bc24c713 Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:47:36 -0000 --047d7b1601bb0c6e4f04bc24c713 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 21, 2012 at 9:23 PM, John Leslie wrote: > Roni Even wrote: > > [Andy Pepperell wrote:] > >> > >> With more thought on this, we also came to the conclusion that the use > for > >> this attribute for video captures doesn't necessarily translate exactly > >> equivalently to audio captures. In a network of cascaded MCUs it *would* > >> often be perfectly acceptable to use a pre-mixed audio stream from a > peer > >> MCU whereas it would be highly desirable to not use pre-composed, > >> multi-pane, video from those media providers. Largely because of the > >> potential different use of the attribute by media stream consumers, our > >> thinking is that we *shouldn't* define the "composed" attribute to > apply to > >> both video and audio captures, and instead use, if required, a separate > >> "mixed" attribute for the audio case. > > I'm not sure it needs to be "separate", but I would hope we have a > tag to show that two or more microphones in different positions were > "mixed" into a single audio stream. > > I view this as a warning label -- and a single bit suffices unless > we include details of the microphones being mixed (which I don't believe > is the current plan). > [sb] Are you suggesting that every system using a steered microphone array would be tagged as "mixed"? I don't see that as helpful, so I think we would need to define the meaning of "mixed" here carefully. > > >> For the specific case of a 3 microphone room which can either provide 3 > >> separate streams to the far end or a single pre-mixed audio stream, we'd > >> anticipate none of these audio captures necessarily being tagged as > "mixed", > >> as this expresses no more information than is provided by the fact that > the > >> 3 capture entry and single capture entry appear as equivalents in the > same > >> capture scene. > > I don't understand: why wouldn't the pre-mixed stream be labeled > "mixed"? > > > I am not sure what is the issue since the MCU knows if this is an audio > or > > video stream and can handle them differently like all MCUs will do today. > > (Use of the same bit seems OK...) > > > For cascading there is a need to know if the consumer is an MCU in order > to > > advertise the right information. This may still be a composed video from > > the end point (like current speaker mixed with pip of others) but not > > composed from an MCU. > > I don't understand Roni here: surely we can set the "composed" bit > if we're sending split-screen regardless of who will receive that stream. > > > I am not sure why you do not want to have the mixed audio from the room > as > > mixed. How do you know if it is mixed or just a pickup of the whole room > by > > one microphone from the three if both advertisements will have the whole > > room co-ordinates, > > Hopefully any software will know if _it_ is mixing two streams: it > would have to depend on an operator to specify that one of the streams > is from a mixer. Since I view this as a warning label, I'd like it to > be passed on. > > > and like I said above the consumer will know if this is audio or video > > Yes. > > > and how to handle it. > > In many cases, it would be handled the same whether mixed or not; but > I can imagine future enhancements which process the audio streams to > different apparent positions in multi-channel audio schemes. > > For our first pass, it's arguably sufficient to take a single mixed > audio stream for each room and process it to a stereo position. But if > we receive more than one audio stream from a room, processing them to > different stereo positions might help. > > (The actual use of a "mixed" bit, as I imagine it, would be to > process the audio to a less-distinct position, and probably softer > than any un-mixed audio streams from that room. If I were also adding > impulse-response, I'd probably add less for a "mixed" stream. The > point is, while the differences are subtle, subtle audio clues can > be very helpful.) > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b1601bb0c6e4f04bc24c713 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 21, 2012 at 9:23 PM, John Le= slie <john@jlc.net= > wrote:
Roni Even <ron.even.tlv@gmail.= com> wrote:
> [Andy Pepperell wrote:]
>>
>> With more thought on this, we also came to the conclusion that the= use for
>> this attribute for video captures doesn't necessarily translat= e exactly
>> equivalently to audio captures. In a network of cascaded MCUs it *= would*
>> often be perfectly acceptable to use a pre-mixed audio stream from= a peer
>> MCU whereas it would be highly desirable to not use pre-composed,<= br> >> multi-pane, video from those media providers. Largely because of t= he
>> potential different use of the attribute by media stream consumers= , our
>> thinking is that we *shouldn't* define the "composed"= ; attribute to apply to
>> both video and audio captures, and instead use, if required, a sep= arate
>> "mixed" attribute for the audio case.

=A0 I'm not sure it needs to be "separate", but I woul= d hope we have a
tag to show that two or more microphones in different positions were
"mixed" into a single audio stream.

=A0 I view this as a warning label -- and a single bit suffices unless
we include details of the microphones being mixed (which I don't believ= e
is the current plan).
[sb]=A0 Are you suggesting that = every system using a steered microphone array would be tagged as "mixe= d"?=A0 I don't see that as helpful, so I think we would need to de= fine the meaning of "mixed" here carefully.

>> For the specific case of a 3 microphone room which can either prov= ide 3
>> separate streams to the far end or a single pre-mixed audio stream= , we'd
>> anticipate none of these audio captures necessarily being tagged a= s "mixed",
>> as this expresses no more information than is provided by the fact= that the
>> 3 capture entry and single capture entry appear as equivalents in = the same
>> capture scene.

=A0 I don't understand: why wouldn't the pre-mixed stream be= labeled
"mixed"?

> I am not sure what is the issue since the MCU knows if this is an audi= o or
> video stream and can handle them differently like all MCUs will do tod= ay.

=A0 (Use of the same bit seems OK...)

> For cascading there is a need to know if the consumer is an MCU in ord= er to
> advertise =A0the right information. This may still be a composed video= from
> the end point (like current speaker mixed with pip of others) but not<= br> > composed from an MCU.

=A0 I don't understand Roni here: surely we can set the "co= mposed" bit
if we're sending split-screen regardless of who will receive that strea= m.

> I am not sure why you do not want to have the mixed audio from the roo= m as
> mixed. How do you know if it is mixed or just a pickup of the whole ro= om by
> one microphone from the three if both advertisements will have the who= le
> room co-ordinates,

=A0 Hopefully any software will know if _it_ is mixing two streams: = it
would have to depend on an operator to specify that one of the streams
is from a mixer. Since I view this as a warning label, I'd like it to be passed on.

> and like I said above the consumer will know if this is audio or video=

=A0 Yes.

> and how to handle it.

=A0 In many cases, it would be handled the same whether mixed or not= ; but
I can imagine future enhancements which process the audio streams to
different apparent positions in multi-channel audio schemes.

=A0 For our first pass, it's arguably sufficient to take a single mixe= d
audio stream for each room and process it to a stereo position. But if
we receive more than one audio stream from a room, processing them to
different stereo positions might help.

=A0 (The actual use of a "mixed" bit, as I imagine it, would be = to
process the audio to a less-distinct position, and probably softer
than any un-mixed audio streams from that room. If I were also adding
impulse-response, I'd probably add less for a "mixed" stream.= The
point is, while the differences are subtle, subtle audio clues can
be very helpful.)

--
John Leslie <john@jlc.net>
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--047d7b1601bb0c6e4f04bc24c713-- From ietf@meetecho.com Mon Mar 26 09:28:26 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A20B21E8044 for ; Mon, 26 Mar 2012 09:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAtRv6VOizPl for ; Mon, 26 Mar 2012 09:28:25 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out22.aruba.it [62.149.158.62]) by ietfa.amsl.com (Postfix) with SMTP id 9FD6A21E80C6 for ; Mon, 26 Mar 2012 09:28:24 -0700 (PDT) Received: (qmail 2467 invoked by uid 89); 26 Mar 2012 16:28:21 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq01.aruba.it with SMTP; 26 Mar 2012 16:28:21 -0000 Received: (qmail 10696 invoked by uid 89); 26 Mar 2012 16:28:21 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp3.ad.aruba.it with SMTP; 26 Mar 2012 16:28:21 -0000 Message-ID: <4F709924.5000704@meetecho.com> Date: Mon, 26 Mar 2012 18:28:20 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [clue] Meetecho support for CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 16:28:26 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Tuesday's CLUE WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/clue The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From john@jlc.net Mon Mar 26 21:13:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C92621E8051 for ; Mon, 26 Mar 2012 21:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.362 X-Spam-Level: X-Spam-Status: No, score=-106.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ0fDY-SC0Uj for ; Mon, 26 Mar 2012 21:13:03 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 942F921E8019 for ; Mon, 26 Mar 2012 21:12:56 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 637CF33C36; Tue, 27 Mar 2012 00:12:55 -0400 (EDT) Date: Tue, 27 Mar 2012 00:12:55 -0400 From: John Leslie To: Stephen Botzko Message-ID: <20120327041255.GB5206@verdi> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 04:13:04 -0000 Stephen Botzko wrote: > On Wed, Mar 21, 2012 at 9:23 PM, John Leslie wrote: >> Roni Even wrote: >>> [Andy Pepperell wrote:] >>>> >>>> With more thought on this, we also came to the conclusion that the use >>>> for this attribute for video captures doesn't necessarily translate >>>> exactly equivalently to audio captures. In a network of cascaded MCUs >>>> it *would* often be perfectly acceptable to use a pre-mixed audio >>>> stream from a peer MCU whereas it would be highly desirable to not >>>> use pre-composed, multi-pane, video from those media providers. (I agree that pre-mixed audio may sometimes be preferred to doing your own mixing, for the same room where pre-composed video would _not_ be preferred.) >>>> Largely because of the potential different use of the attribute by >>>> media stream consumers, our thinking is that we *shouldn't* define >>>> the "composed" attribute to apply to both video and audio captures, >>>> and instead use, if required, a separate "mixed" attribute for the >>>> audio case. >> >> I'm not sure it needs to be "separate", but I would hope we have a >> tag to show that two or more microphones in different positions were >> "mixed" into a single audio stream. >> >> I view this as a warning label -- and a single bit suffices unless >> we include details of the microphones being mixed (which I don't believe >> is the current plan). >> > [sb] Are you suggesting that every system using a steered microphone array > would be tagged as "mixed"? Actually, yes: in the case of a steered _array_ of microphones, the arrival-time information will be lost, just as in an audio mixer with multiple microphones. This is distinct from the case of a steered "shotgun" microphone where the mike position is fixed (though its directional pattern changes), thus arrival-time information is preserved. > I don't see that as helpful, so I think we would need to define the > meaning of "mixed" here carefully. We probably do need a careful definition... To me, the essential point is that a mixer greatly obscures any ability to process for actual physical location of the microphone -- thus I'm probably going to fail if I try to aid the listeners in recovering the actual physical location of the speaker(s). Of course, regardless of our definition, such a "mixed" bit will end up being set wrong sometimes -- but I'd still like the warning label. In an actual room, listeners with binaural hearing determine the speaker's location quite unconsciously -- but they do use physical position as one input into speaker recognition (and where to focus their attention). When a remote speaker is presented through a monophonic speaker, they describe it as a "dissociated voice" and are subconsciously confused. Given "mixed" audio, I can still process it to a single apparent position, but I can't relate that position to any other sound source; nor can I usefully vary it as different speakers are included in that audio stream. -- John Leslie From stephen.botzko@gmail.com Tue Mar 27 07:14:23 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C81021F8815 for ; Tue, 27 Mar 2012 07:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9WhoTjKGYqj for ; Tue, 27 Mar 2012 07:14:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6226321F87C7 for ; Tue, 27 Mar 2012 07:14:21 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5164782ghb.31 for ; Tue, 27 Mar 2012 07:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kRTgUHw6PVuzdDkTSwNepswU+1UUrbXXsXhzRlTX/mE=; b=N6vuRbLMc4Yq2dUsCG1G2h+Oxb08PiI5zhRR3UcqPYES0fbQnJNRqA+XLZT4of4zfM pmKPnwTr3zT76OKcaXhocqxo3zQWmjkTL16EkgKvN6l80zQzs67JNc3fLjV6TO4Qv31+ RHvVGNO9lSoYaYhDGGKAJaOlwZ14TjuLiV4i1QF18YO49dq4S/Q+BuXlj271+EAduo53 zvDGxg230nudGXJslKjCImrVNkY1kuM0iuTgUgw99ZngOmvECKfTgbuZYS9J7x6az1oP iWLrhBkl6NaqepfrdmPhqisLjhsdtLH7g67/ju0OEMAGbnLIaHatRJRoezJOcBN7xNED IhNA== MIME-Version: 1.0 Received: by 10.68.197.39 with SMTP id ir7mr25794108pbc.17.1332857660652; Tue, 27 Mar 2012 07:14:20 -0700 (PDT) Received: by 10.68.32.37 with HTTP; Tue, 27 Mar 2012 07:14:20 -0700 (PDT) In-Reply-To: <20120327041255.GB5206@verdi> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> Date: Tue, 27 Mar 2012 16:14:20 +0200 Message-ID: From: Stephen Botzko To: John Leslie Content-Type: multipart/alternative; boundary=e89a8ff1c0b4663d9a04bc3a1b34 Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:14:23 -0000 --e89a8ff1c0b4663d9a04bc3a1b34 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 27, 2012 at 6:12 AM, John Leslie wrote: > Stephen Botzko wrote: > > On Wed, Mar 21, 2012 at 9:23 PM, John Leslie wrote: > >> Roni Even wrote: > >>> [Andy Pepperell wrote:] > >>>> > >>>> With more thought on this, we also came to the conclusion that the use > >>>> for this attribute for video captures doesn't necessarily translate > >>>> exactly equivalently to audio captures. In a network of cascaded MCUs > >>>> it *would* often be perfectly acceptable to use a pre-mixed audio > >>>> stream from a peer MCU whereas it would be highly desirable to not > >>>> use pre-composed, multi-pane, video from those media providers. > > (I agree that pre-mixed audio may sometimes be preferred to doing > your own mixing, for the same room where pre-composed video would _not_ > be preferred.) > > >>>> Largely because of the potential different use of the attribute by > >>>> media stream consumers, our thinking is that we *shouldn't* define > >>>> the "composed" attribute to apply to both video and audio captures, > >>>> and instead use, if required, a separate "mixed" attribute for the > >>>> audio case. > >> > >> I'm not sure it needs to be "separate", but I would hope we have a > >> tag to show that two or more microphones in different positions were > >> "mixed" into a single audio stream. > >> > >> I view this as a warning label -- and a single bit suffices unless > >> we include details of the microphones being mixed (which I don't believe > >> is the current plan). > >> > > [sb] Are you suggesting that every system using a steered microphone > array > > would be tagged as "mixed"? > > Actually, yes: in the case of a steered _array_ of microphones, the > arrival-time information will be lost, just as in an audio mixer with > multiple microphones. > > This is distinct from the case of a steered "shotgun" microphone where > the mike position is fixed (though its directional pattern changes), thus > arrival-time information is preserved. > > [sb] I believe steered microphone arrays are used commonly in sonar acquisition, so I don't believe arrival time information has to be lost. Usually the microphones in such an array are in fixed positions. > > I don't see that as helpful, so I think we would need to define the > > meaning of "mixed" here carefully. > > We probably do need a careful definition... > > To me, the essential point is that a mixer greatly obscures any > ability to process for actual physical location of the microphone -- > thus I'm probably going to fail if I try to aid the listeners in > recovering the actual physical location of the speaker(s). > > Of course, regardless of our definition, such a "mixed" bit will end > up being set wrong sometimes -- but I'd still like the warning label. > > In an actual room, listeners with binaural hearing determine the > speaker's location quite unconsciously -- but they do use physical > position as one input into speaker recognition (and where to focus > their attention). When a remote speaker is presented through a > monophonic speaker, they describe it as a "dissociated voice" and > are subconsciously confused. > > Given "mixed" audio, I can still process it to a single apparent > position, but I can't relate that position to any other sound source; > nor can I usefully vary it as different speakers are included in that > audio stream. > > -- > John Leslie > --e89a8ff1c0b4663d9a04bc3a1b34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 27, 2012 at 6:12 AM, John Le= slie <john@jlc.net= > wrote:
Stephen Botzko <stephen.botzko@gmail.com> wrote:
> On Wed, Mar 21, 2012 at 9:23 PM, John Leslie <john@jlc.net> wrote:
>> Roni Even <ron.even.t= lv@gmail.com> wrote:
>>> [Andy Pepperell wrote:]
>>>>
>>>> With more thought on this, we also came to the conclusion = that the use
>>>> for this attribute for video captures doesn't necessar= ily translate
>>>> exactly equivalently to audio captures. In a network of ca= scaded MCUs
>>>> it *would* often be perfectly acceptable to use a pre-mixe= d audio
>>>> stream from a peer MCU whereas it would be highly desirabl= e to not
>>>> use pre-composed, multi-pane, video from those media provi= ders.

=A0 (I agree that pre-mixed audio may sometimes be preferred to doin= g
your own mixing, for the same room where pre-composed video would _not_
be preferred.)

>>>> Largely because of the potential different use of the attr= ibute by
>>>> media stream consumers, our thinking is that we *shouldn&#= 39;t* define
>>>> the "composed" attribute to apply to both video = and audio captures,
>>>> and instead use, if required, a separate "mixed"= attribute for the
>>>> audio case.
>>
>> I'm not sure it needs to be "separate", but I would = hope we have a
>> tag to show that two or more microphones in different positions we= re
>> "mixed" into a single audio stream.
>>
>> I view this as a warning label -- and a single bit suffices unless=
>> we include details of the microphones being mixed (which I don'= ;t believe
>> is the current plan).
>>
> [sb] =A0Are you suggesting that every system using a steered microphon= e array
> would be tagged as "mixed"?

=A0 Actually, yes: in the case of a steered _array_ of microphones, = the
arrival-time information will be lost, just as in an audio mixer with
multiple microphones.

=A0 This is distinct from the case of a steered "shotgun" microp= hone where
the mike position is fixed (though its directional pattern changes), thus arrival-time information is preserved.

[sb] I believe steered microp= hone arrays are used commonly in sonar acquisition, so I don't believe = arrival time information has to be lost.=A0 Usually the microphones in such= an array are in fixed positions.
=A0
> I don't see that as helpful, so I think we would need to define th= e
> meaning of "mixed" here carefully.

=A0 We probably do need a careful definition...

=A0 To me, the essential point is that a mixer greatly obscures any
ability to process for actual physical location of the microphone --
thus I'm probably going to fail if I try to aid the listeners in
recovering the actual physical location of the speaker(s).

=A0 Of course, regardless of our definition, such a "mixed" bit = will end
up being set wrong sometimes -- but I'd still like the warning label.
=A0 In an actual room, listeners with binaural hearing determine the
speaker's location quite unconsciously -- but they do use physical
position as one input into speaker recognition (and where to focus
their attention). When a remote speaker is presented through a
monophonic speaker, they describe it as a "dissociated voice" and=
are subconsciously confused.

=A0 Given "mixed" audio, I can still process it to a single appa= rent
position, but I can't relate that position to any other sound source; nor can I usefully vary it as different speakers are included in that
audio stream.

--
John Leslie <john@jlc.net>

--e89a8ff1c0b4663d9a04bc3a1b34-- From ietf@meetecho.com Tue Mar 27 12:22:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA10221F872F for ; Tue, 27 Mar 2012 12:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.859 X-Spam-Level: X-Spam-Status: No, score=-0.859 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6DxvNYI8253 for ; Tue, 27 Mar 2012 12:22:58 -0700 (PDT) Received: from smtplq02.aruba.it (smtplqs-out28.aruba.it [62.149.158.68]) by ietfa.amsl.com (Postfix) with SMTP id ECEF321F8678 for ; Tue, 27 Mar 2012 12:22:57 -0700 (PDT) Received: (qmail 1709 invoked by uid 89); 27 Mar 2012 19:22:53 -0000 Received: from unknown (HELO smtp4.aruba.it) (62.149.158.224) by smtplq02.aruba.it with SMTP; 27 Mar 2012 19:22:53 -0000 Received: (qmail 20404 invoked by uid 89); 27 Mar 2012 19:22:53 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp4.ad.aruba.it with SMTP; 27 Mar 2012 19:22:53 -0000 Message-ID: <4F721389.1060209@meetecho.com> Date: Tue, 27 Mar 2012 21:22:49 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp4.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [clue] Meetecho session recording available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 19:22:59 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of CLUE session at IETF-83 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf83/recordings#CLUE_IETF83 For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From john@jlc.net Tue Mar 27 15:32:13 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F224A21E8128 for ; Tue, 27 Mar 2012 15:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.365 X-Spam-Level: X-Spam-Status: No, score=-106.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s885IcvO8Iab for ; Tue, 27 Mar 2012 15:32:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 670D421E8011 for ; Tue, 27 Mar 2012 15:32:12 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 96AE333C28; Tue, 27 Mar 2012 18:32:12 -0400 (EDT) Date: Tue, 27 Mar 2012 18:32:12 -0400 From: John Leslie To: Stephen Botzko Message-ID: <20120327223212.GC5206@verdi> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: [clue] Steered microphone arrays X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:32:13 -0000 Stephen Botzko wrote: > On Tue, Mar 27, 2012 at 6:12 AM, John Leslie wrote: >> Stephen Botzko wrote: >> >>> [sb] Are you suggesting that every system using a steered microphone >>> array would be tagged as "mixed"? >> >> Actually, yes: in the case of a steered _array_ of microphones, the >> arrival-time information will be lost, just as in an audio mixer with >> multiple microphones. >> >> This is distinct from the case of a steered "shotgun" microphone where >> the mike position is fixed (though its directional pattern changes), thus >> arrival-time information is preserved. >> >> [sb] I believe steered microphone arrays are used commonly in sonar >> acquisition, This is true... >> so I don't believe arrival time information has to be lost. >> Usually the microphones in such an array are in fixed positions. As usual, the devil is in the details... In sonar, there's a very clearly-positioned sound source, and the return times of the microphone array are calibrated to that source. (Actually, the source likely produces a "chirp" of varying wavelength and the phase differences are processed during the chirp response.) In our microphone array, the position of the sound source is variable and there's no control of its wavelengths. It is technically possible to compare phase information of several microphones and process the sound output to that which "would be received" by a mike at a given position (within the range of the microphone array, of course); but if any existing system does that, I haven't heard of it. Again, we're going to have to trust operators to set the "mixed" bit: we can only offer guidance... -- John Leslie From pkyzivat@alum.mit.edu Tue Mar 27 23:33:00 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1188C21F8759 for ; Tue, 27 Mar 2012 23:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZ9kIMA0XCCm for ; Tue, 27 Mar 2012 23:32:59 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id A25CD21F8758 for ; Tue, 27 Mar 2012 23:32:59 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta09.emeryville.ca.mail.comcast.net with comcast id quY81i0031afHeLA9uYz9u; Wed, 28 Mar 2012 06:32:59 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta17.emeryville.ca.mail.comcast.net with comcast id quYp1i00R5EhBnE8duYsv1; Wed, 28 Mar 2012 06:32:57 +0000 Message-ID: <4F723272.4040409@alum.mit.edu> Date: Tue, 27 Mar 2012 23:34:42 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> In-Reply-To: <20120327041255.GB5206@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 06:33:00 -0000 [I don't know if this is as chair or individual. Maybe both.] The discussion of the composed and mixed attributes today exposed a lot of vagueness about what they mean. I think this needs to be firmed up considerably. Here are some thoughts of my own just to keep the discussion going: Regarding mixed (audio): The fact that an audio capture has mixed content doesn't preclude mixing it again. But there are properties of it that might make such mixing unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then it is ok to mix AC3 and independent capture AC4. But it would be unwise to mix it with AC2 again. And it would also be unwise to mix it with AC5 that is itself a mix of (AC1, AC4). It *might* also be the case that a mix is unwise if it includes (transitively) too many original inputs. Fundamentally it seems like the decision of whether a mix makes sense requires some complex decision making based on way more data than whether the immediate inputs are themselves mixed or not. Regarding composed (video): This seems potentially more complex. So far the only use I have heard for this attribute is to drive a decision about whether it makes sense to compose this capture with others. But I expect that isn't always true either. You could have one uncomposed capture that shows two people (heads) side by side. You could have another *composed* capture that also shows two people in independently side by side each inside a frame, that were assembled from other captures. (Would anyone argue that this isn't composed?) But I can't see why it would be any more or less desirable to compose one of these captures than another. Again it seems like you need more information about what has been composed, and at what scale (and maybe position) before you can make a decision about whether it makes sense to compose it. And then that may also depend on *how* you want to compose it. If mixed and composed aren't intended to drive decisions about further mixing and composing, then what *are* they for? Thanks, Paul From Mark.Duckworth@polycom.com Wed Mar 28 01:52:42 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F5821F88A9 for ; Wed, 28 Mar 2012 01:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iXUgpboSEab for ; Wed, 28 Mar 2012 01:52:41 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8890721F88BB for ; Wed, 28 Mar 2012 01:52:40 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 28 Mar 2012 01:52:40 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 28 Mar 2012 01:52:35 -0700 Thread-Topic: [clue] Use of the media capture "composed" attribute Thread-Index: Ac0MrKGVxg7+pDbsTEW9tAyKbnc+ggAEfEtA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <4F723272.4040409@alum.mit.edu> In-Reply-To: <4F723272.4040409@alum.mit.edu> 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: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:52:42 -0000 Paul asked: > If mixed and composed aren't intended to drive decisions about further > mixing and composing, then what *are* they for? I was thinking one other case where the composed attribute would be used is= when a consumer (an endpoint in this case) is choosing which media capture= s to receive from a provider. Suppose the provider advertises capture scen= e entries that are the same except one of them has video captures that use = composed=3Dtrue, and the other uses composed=3Dfalse. I think the consumer= can reasonably assume the one with composed=3Dtrue includes more informati= on somehow, possibly with "Hollywood squares" or picture-in-picture video l= ayout. The consumer can use this limited information to make a choice. Th= is choice has nothing to do with whether or not the receiving endpoint is g= oing to re-compose the images. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, March 27, 2012 11:35 PM > To: clue@ietf.org > Subject: Re: [clue] Use of the media capture "composed" attribute >=20 > [I don't know if this is as chair or individual. Maybe both.] >=20 > The discussion of the composed and mixed attributes today exposed a lot o= f > vagueness about what they mean. I think this needs to be firmed up > considerably. >=20 > Here are some thoughts of my own just to keep the discussion going: >=20 > Regarding mixed (audio): >=20 > The fact that an audio capture has mixed content doesn't preclude mixing = it > again. But there are properties of it that might make such mixing > unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then it is o= k to mix > AC3 and independent capture AC4. But it would be unwise to mix it with AC= 2 > again. And it would also be unwise to mix it with AC5 that is itself a mi= x of > (AC1, AC4). >=20 > It *might* also be the case that a mix is unwise if it includes > (transitively) too many original inputs. >=20 > Fundamentally it seems like the decision of whether a mix makes sense > requires some complex decision making based on way more data than > whether the immediate inputs are themselves mixed or not. >=20 > Regarding composed (video): >=20 > This seems potentially more complex. So far the only use I have heard for > this attribute is to drive a decision about whether it makes sense to com= pose > this capture with others. But I expect that isn't always true either. You= could > have one uncomposed capture that shows two people > (heads) side by side. You could have another *composed* capture that also > shows two people in independently side by side each inside a frame, that > were assembled from other captures. (Would anyone argue that this isn't > composed?) But I can't see why it would be any more or less desirable to > compose one of these captures than another. >=20 > Again it seems like you need more information about what has been > composed, and at what scale (and maybe position) before you can make a > decision about whether it makes sense to compose it. And then that may > also depend on *how* you want to compose it. >=20 > If mixed and composed aren't intended to drive decisions about further > mixing and composing, then what *are* they for? >=20 > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Mar 28 02:06:38 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172E821F8A0C for ; Wed, 28 Mar 2012 02:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.52 X-Spam-Level: X-Spam-Status: No, score=-6.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYDS9-S0-7pQ for ; Wed, 28 Mar 2012 02:06:37 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id D62C721F89FD for ; Wed, 28 Mar 2012 02:06:35 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 28 Mar 2012 02:06:34 -0700 From: "Duckworth, Mark" To: John Leslie , "clue@ietf.org" Date: Wed, 28 Mar 2012 02:06:31 -0700 Thread-Topic: audio mixed attribute Thread-Index: Ac0Mwf3FTv4hlpqLR9KF/bIjszDxtA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@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: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:06:38 -0000 Hi John, I'm trying to understand your view on labeling audio as mixed. Here is one example scenario that might help me understand. Suppose I am a provider, and I can capture and send audio in two different = ways: Option 1: I can send one mono audio capture. It comes from one microphone = element that picks up audio from the whole room. Option 2: I can send one mono audio capture. It comes from several microph= one elements mixed together, that collectively pick up audio from the whole= room. I think you are saying it would be useful to label option 1 as not mixed, a= nd label option 2 as mixed. Is that correct? What might a receiver do differently if it receives option 1 vs. receiving = option 2? Regards, Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > John Leslie > Sent: Tuesday, March 27, 2012 6:13 AM > To: Stephen Botzko > Cc: clue@ietf.org > Subject: Re: [clue] Use of the media capture "composed" attribute >=20 > Stephen Botzko wrote: > > On Wed, Mar 21, 2012 at 9:23 PM, John Leslie wrote: > >> Roni Even wrote: > >>> [Andy Pepperell wrote:] > >>>> > >>>> With more thought on this, we also came to the conclusion that the > >>>> use for this attribute for video captures doesn't necessarily > >>>> translate exactly equivalently to audio captures. In a network of > >>>> cascaded MCUs it *would* often be perfectly acceptable to use a > >>>> pre-mixed audio stream from a peer MCU whereas it would be highly > >>>> desirable to not use pre-composed, multi-pane, video from those > media providers. >=20 > (I agree that pre-mixed audio may sometimes be preferred to doing your > own mixing, for the same room where pre-composed video would _not_ be > preferred.) >=20 > >>>> Largely because of the potential different use of the attribute by > >>>> media stream consumers, our thinking is that we *shouldn't* define > >>>> the "composed" attribute to apply to both video and audio captures, > >>>> and instead use, if required, a separate "mixed" attribute for the > >>>> audio case. > >> > >> I'm not sure it needs to be "separate", but I would hope we have a > >> tag to show that two or more microphones in different positions were > >> "mixed" into a single audio stream. > >> > >> I view this as a warning label -- and a single bit suffices unless we > >> include details of the microphones being mixed (which I don't believe > >> is the current plan). > >> > > [sb] Are you suggesting that every system using a steered microphone > > array would be tagged as "mixed"? >=20 > Actually, yes: in the case of a steered _array_ of microphones, the ar= rival- > time information will be lost, just as in an audio mixer with multiple > microphones. >=20 > This is distinct from the case of a steered "shotgun" microphone where= the > mike position is fixed (though its directional pattern changes), thus arr= ival- > time information is preserved. >=20 > > I don't see that as helpful, so I think we would need to define the > > meaning of "mixed" here carefully. >=20 > We probably do need a careful definition... >=20 > To me, the essential point is that a mixer greatly obscures any abilit= y to > process for actual physical location of the microphone -- thus I'm probab= ly > going to fail if I try to aid the listeners in recovering the actual phys= ical > location of the speaker(s). >=20 > Of course, regardless of our definition, such a "mixed" bit will end u= p being > set wrong sometimes -- but I'd still like the warning label. >=20 > In an actual room, listeners with binaural hearing determine the speak= er's > location quite unconsciously -- but they do use physical position as one = input > into speaker recognition (and where to focus their attention). When a > remote speaker is presented through a monophonic speaker, they describe > it as a "dissociated voice" and are subconsciously confused. >=20 > Given "mixed" audio, I can still process it to a single apparent posit= ion, but I > can't relate that position to any other sound source; nor can I usefully = vary it > as different speakers are included in that audio stream. >=20 > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From ietf@meetecho.com Wed Mar 28 22:49:55 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C1F21E8042 for ; Wed, 28 Mar 2012 22:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KImMFvNHKIfv for ; Wed, 28 Mar 2012 22:49:55 -0700 (PDT) Received: from smtplq01.aruba.it (smtplqs-out27.aruba.it [62.149.158.67]) by ietfa.amsl.com (Postfix) with SMTP id 5D7F721E8015 for ; Wed, 28 Mar 2012 22:49:54 -0700 (PDT) Received: (qmail 29209 invoked by uid 89); 29 Mar 2012 05:49:52 -0000 Received: from unknown (HELO smtp7.aruba.it) (62.149.158.227) by smtplq01.aruba.it with SMTP; 29 Mar 2012 05:49:52 -0000 Received: (qmail 9858 invoked by uid 89); 29 Mar 2012 05:49:52 -0000 Received: from unknown (HELO ?192.168.0.40?) (alex@meetecho.com@78.192.151.119) by smtp7.ad.aruba.it with ESMTPA; 29 Mar 2012 05:49:52 -0000 Message-ID: <4F73F7FA.9000009@meetecho.com> Date: Thu, 29 Mar 2012 07:49:46 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: clue@ietf.org References: <4F709924.5000704@meetecho.com> In-Reply-To: <4F709924.5000704@meetecho.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: Re: [clue] Meetecho support for CLUE WG session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 05:49:55 -0000 All, the information below are also valid for today's meeting! Cheers, the Meetecho team Il 26/03/2012 18:28, Meetecho IETF support ha scritto: > Hi all, > > a virtual room has been reserved on the Meetecho system for Tuesday's > CLUE WG meeting session. > > Access to the on-line session (including audio and video streams) will > be available at: > http://www.meetecho.com/ietf83/clue > > The Meetecho session automatically logs you into the standard IETF > jabber room. So, from there, you can have an integrated experience > involving all media and allowing you to interact with the room. > Remote participants might also send their own voice to the room, if they > want to. > > A tutorial of interactivity features of the tool can be found at: > http://www.meetecho.com/ietf83/tutorials > > Cheers, > the Meetecho team > From pkyzivat@alum.mit.edu Thu Mar 29 05:09:18 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAAE21F8A45 for ; Thu, 29 Mar 2012 05:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLE9QP+fzCo3 for ; Thu, 29 Mar 2012 05:09:18 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id C3C9A21F8A48 for ; Thu, 29 Mar 2012 05:09:16 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id rQ781i0030QuhwU59Q9Hm9; Thu, 29 Mar 2012 12:09:17 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta02.westchester.pa.mail.comcast.net with comcast id rQ961i00P5EhBnE3NQ98mR; Thu, 29 Mar 2012 12:09:15 +0000 Message-ID: <4F738516.2000209@alum.mit.edu> Date: Wed, 28 Mar 2012 23:39:34 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: "Duckworth, Mark" References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi> <20120327041255.GB5206@verdi> <4F723272.4040409@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:09:18 -0000 I think this further verifies that we need a better explanation of the intended purpose(s) of these (mixed/composed) attributes so that we can assess whether we have an actionable definition sufficient to the need. Thanks, Paul On 3/28/12 10:52 AM, Duckworth, Mark wrote: > Paul asked: >> If mixed and composed aren't intended to drive decisions about further >> mixing and composing, then what *are* they for? > > I was thinking one other case where the composed attribute would be used is when a consumer (an endpoint in this case) is choosing which media captures to receive from a provider. Suppose the provider advertises capture scene entries that are the same except one of them has video captures that use composed=true, and the other uses composed=false. I think the consumer can reasonably assume the one with composed=true includes more information somehow, possibly with "Hollywood squares" or picture-in-picture video layout. The consumer can use this limited information to make a choice. This choice has nothing to do with whether or not the receiving endpoint is going to re-compose the images. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, March 27, 2012 11:35 PM >> To: clue@ietf.org >> Subject: Re: [clue] Use of the media capture "composed" attribute >> >> [I don't know if this is as chair or individual. Maybe both.] >> >> The discussion of the composed and mixed attributes today exposed a lot of >> vagueness about what they mean. I think this needs to be firmed up >> considerably. >> >> Here are some thoughts of my own just to keep the discussion going: >> >> Regarding mixed (audio): >> >> The fact that an audio capture has mixed content doesn't preclude mixing it >> again. But there are properties of it that might make such mixing >> unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then it is ok to mix >> AC3 and independent capture AC4. But it would be unwise to mix it with AC2 >> again. And it would also be unwise to mix it with AC5 that is itself a mix of >> (AC1, AC4). >> >> It *might* also be the case that a mix is unwise if it includes >> (transitively) too many original inputs. >> >> Fundamentally it seems like the decision of whether a mix makes sense >> requires some complex decision making based on way more data than >> whether the immediate inputs are themselves mixed or not. >> >> Regarding composed (video): >> >> This seems potentially more complex. So far the only use I have heard for >> this attribute is to drive a decision about whether it makes sense to compose >> this capture with others. But I expect that isn't always true either. You could >> have one uncomposed capture that shows two people >> (heads) side by side. You could have another *composed* capture that also >> shows two people in independently side by side each inside a frame, that >> were assembled from other captures. (Would anyone argue that this isn't >> composed?) But I can't see why it would be any more or less desirable to >> compose one of these captures than another. >> >> Again it seems like you need more information about what has been >> composed, and at what scale (and maybe position) before you can make a >> decision about whether it makes sense to compose it. And then that may >> also depend on *how* you want to compose it. >> >> If mixed and composed aren't intended to drive decisions about further >> mixing and composing, then what *are* they for? >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From john@jlc.net Thu Mar 29 08:26:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1A21E813B for ; Thu, 29 Mar 2012 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.371 X-Spam-Level: X-Spam-Status: No, score=-106.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJAhHZCXGQDo for ; Thu, 29 Mar 2012 08:26:02 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id ED9C021E8204 for ; Thu, 29 Mar 2012 08:26:01 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 0042633C24; Thu, 29 Mar 2012 11:26:00 -0400 (EDT) Date: Thu, 29 Mar 2012 11:26:00 -0400 From: John Leslie To: "Duckworth, Mark" Message-ID: <20120329152600.GB67516@verdi> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:26:02 -0000 Duckworth, Mark wrote: > > Hi John, > I'm trying to understand your view on labeling audio as mixed. > Here is one example scenario that might help me understand. > Suppose I am a provider, and I can capture and send audio in two > different ways: > Option 1: I can send one mono audio capture. It comes from one > microphone element that picks up audio from the whole room. > Option 2: I can send one mono audio capture. It comes from several > microphone elements mixed together, that collectively pick > up audio from the whole room. > > I think you are saying it would be useful to label option 1 as not > mixed, and label option 2 as mixed. Is that correct? Yes. > What might a receiver do differently if it receives option 1 vs. > receiving option 2? (To answer, I need to assume the receiver can to some degree choose which to receive.) The receiver, for example, could reasonably guess that the "mixed" version will have a more uniform level when speakers are in different parts of the room. There's always a trade-off in applyinng level "correction" in order to improve comprehension -- this might be more necessary for the "unmixed" audio. My concern, actually, is more with how to "audibly" "place" the received audio in a virtual room. I believe the "mixed" version needs to be given a less-distinct "place" than the "unmixed". YMMV, of course. There's another issue, hopefully less abstruse: when working from _both_ mixed and unmixed audio captures: the receiver needs to be careful about mixing pre-mixed sources. The nature of sound is a very slow propagation rate in air: roughly one foot per millisecond. The echo of blending sound from one speaker with 100 millisecond propagation difference is obvious -- but the ear can be confused by apparent acoustic effects with differences much smaller than that. The human ear adjusts pretty well to different acoustics if they're constant, but gets confused about apparent position if these acoustic effects change unpredictably. This is probably not anything most of us want to worry about in our initial release: I am thinking ahead, hoping to avoid need to kludge something later on. Folks are already used to "surround-sound" home theatres: we should have some idea how to use such sound systems when we get a round-tuit. ;^) -- John Leslie From espeberg@cisco.com Thu Mar 29 09:50:41 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AE421F8981 for ; Thu, 29 Mar 2012 09:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdnF7Dy5xl6j for ; Thu, 29 Mar 2012 09:50:40 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6131A21F897F for ; Thu, 29 Mar 2012 09:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=3388; q=dns/txt; s=iport; t=1333039839; x=1334249439; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SHpeqV+2NhkFU/oJ8TblMqLX0gJaZar6LOmNZQys/j8=; b=a9jPMHGBN9KKp8idNOgMrxziFvwAq9GHpxlRhdGNzu7O9/Bj74E/G1WH Ve9UsLa03WVdMpwpSwbIrR947B+TN2ahELfPv1FZsXjQDPOajd50fghrb 1uhQPumVtyi2nXM9fL08a4zBUBy8D5lq72sQ6xkWlC5dDkuVW3EQPBjBP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALKRdE+Q/khR/2dsb2JhbABFuROBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQTCBqHYwULnAifKASQPGMEpCeBaIJp X-IronPort-AV: E=Sophos;i="4.73,669,1325462400"; d="scan'208";a="69675043" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2012 16:50:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2TGoc1U017545; Thu, 29 Mar 2012 16:50:38 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 18:50:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 18:50:37 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> In-Reply-To: <20120329152600.GB67516@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] audio mixed attribute Thread-Index: Ac0NwEPwO934GrWmTVG5y5VL2K97EgACVN7g References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> From: "Espen Berger (espeberg)" To: "John Leslie" , "Duckworth, Mark" X-OriginalArrivalTime: 29 Mar 2012 16:50:38.0121 (UTC) FILETIME=[11787990:01CD0DCC] Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:50:41 -0000 John, you have listed a set of valid acoustical challenges which I recognize from our experience. Some of the acoustical challenges will be present if a room use 1 or 2+ microphones to record, e.g. when a person moves around in the room. We should thrust endpoints that chooses to use multiple microphones for capture to do proper audio pre-processing, and keep the audio quality.=20 I would suggest that we reserve the mixed attribute to scenarios where a middle box mix audio captures from different endpoints.=20 Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie Sent: 29. mars 2012 17:26 To: Duckworth, Mark Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute Duckworth, Mark wrote: >=20 > Hi John, > I'm trying to understand your view on labeling audio as mixed. > Here is one example scenario that might help me understand. > Suppose I am a provider, and I can capture and send audio in two=20 > different ways: > Option 1: I can send one mono audio capture. It comes from one > microphone element that picks up audio from the whole room. > Option 2: I can send one mono audio capture. It comes from several > microphone elements mixed together, that collectively pick > up audio from the whole room. >=20 > I think you are saying it would be useful to label option 1 as not=20 > mixed, and label option 2 as mixed. Is that correct? Yes. > What might a receiver do differently if it receives option 1 vs. > receiving option 2? (To answer, I need to assume the receiver can to some degree choose which to receive.) The receiver, for example, could reasonably guess that the "mixed" version will have a more uniform level when speakers are in different parts of the room. There's always a trade-off in applyinng level "correction" in order to improve comprehension -- this might be more necessary for the "unmixed" audio. My concern, actually, is more with how to "audibly" "place" the received audio in a virtual room. I believe the "mixed" version needs to be given a less-distinct "place" than the "unmixed". YMMV, of course. There's another issue, hopefully less abstruse: when working from _both_ mixed and unmixed audio captures: the receiver needs to be careful about mixing pre-mixed sources. The nature of sound is a very slow propagation rate in air: roughly one foot per millisecond. The echo of blending sound from one speaker with 100 millisecond propagation difference is obvious -- but the ear can be confused by apparent acoustic effects with differences much smaller than that. The human ear adjusts pretty well to different acoustics if they're constant, but gets confused about apparent position if these acoustic effects change unpredictably. This is probably not anything most of us want to worry about in our initial release: I am thinking ahead, hoping to avoid need to kludge something later on. Folks are already used to "surround-sound" home theatres: we should have some idea how to use such sound systems when we get a round-tuit. ;^) -- John Leslie _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From john@jlc.net Thu Mar 29 10:18:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDB121E8098 for ; Thu, 29 Mar 2012 10:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.374 X-Spam-Level: X-Spam-Status: No, score=-106.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50qZNGA99tJ5 for ; Thu, 29 Mar 2012 10:18:43 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 62FA421E8053 for ; Thu, 29 Mar 2012 10:18:43 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 54A8233C23; Thu, 29 Mar 2012 13:18:43 -0400 (EDT) Date: Thu, 29 Mar 2012 13:18:43 -0400 From: John Leslie To: "Espen Berger (espeberg)" Message-ID: <20120329171843.GC67516@verdi> References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:18:44 -0000 Espen Berger (espeberg) wrote: > > John, you have listed a set of valid acoustical challenges which I > recognize from our experience. Some of the acoustical challenges will be > present if a room use 1 or 2+ microphones to record, e.g. when a person > moves around in the room. This is true. > We should thrust endpoints that chooses to use multiple microphones for > capture to do proper audio pre-processing, and keep the audio quality. I do not intend anything other than trusting endpoint operators. But there are inherent differences between single-pickup and multiple pickups mixed. For many purposes, multiple pickups will be better... > I would suggest that we reserve the mixed attribute to scenarios where a > middle box mix audio captures from different endpoints. I don't believe it helpful to define "mixed" based on where the mixing is done. You raise a valid point about "mixing" audio from different rooms. This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd rather it not be an ordinary offer. When I describe "mixed" as a warning-label, I did not mean to infer that "mixed" means "low-quality". It sounds to me as if we should seriously consider including a description of _what_ is being mixed... -- John Leslie From ietf@meetecho.com Thu Mar 29 11:04:49 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5843E21E804A for ; Thu, 29 Mar 2012 11:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.287 X-Spam-Level: X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjMe7XiGuTD1 for ; Thu, 29 Mar 2012 11:04:48 -0700 (PDT) Received: from smtpw1.aruba.it (smtpw.aruba.it [62.149.157.41]) by ietfa.amsl.com (Postfix) with SMTP id 2BA7F21E805F for ; Thu, 29 Mar 2012 11:04:47 -0700 (PDT) Received: (qmail 2876 invoked by uid 89); 29 Mar 2012 18:04:42 -0000 Received: from unknown (HELO meetecho.com) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 29 Mar 2012 18:04:42 -0000 Date: Thu, 29 Mar 2012 20:04:42 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: multipart/alternative; boundary="_=__=_XaM3_.1333044282.2A.502763.42.8544.52.42.007.799106351" From: "Meetecho IETF support" To: clue@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.24 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N Subject: [clue] Meetecho session recording available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 18:04:49 -0000 --_=__=_XaM3_.1333044282.2A.502763.42.8544.52.42.007.799106351 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,the full recording (synchronized video, audio, slides and jabber= room)of CLUE II session at IETF-83 is available.You can watch it by eith= er clicking the proper link on the remote participation page (http://www.= ietf.org/meeting/83/remote-participation.html#Meetecho), or by directly a= ccessing the following URL:http://ietf83.conf.meetecho.com/index.php/Reco= rded_Sessions#CLUE_II_IETF83For the chair(s): please feel free to put the= link to the recording in the minutes, if you think this might be useful.= In case of problems with the playout, just drop an e-mail toteam@meetecho= .com.Cheers,the Meetecho team=0A=C2=A0=0AMeetecho s.r.l.=0AWeb Conferenci= ng and Collaboration Tools=0Awww.meetecho.com=0A=C2=A0 --_=__=_XaM3_.1333044282.2A.502763.42.8544.52.42.007.799106351 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =0A
=0A
Dear all,

the full recording (synchroni= zed video, audio, slides and jabber room)
of CLUE II session at IETF-8= 3 is available.

You can watch it by either clicking the proper lin= k on the remote participation page (http://www.ietf.org/meeting/83/remote= -participation.html#Meetecho), or by directly accessing the following URL= :
http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions#CLUE_II_= IETF83

For the chair(s): please feel free to put the link to the r= ecording in the minutes, if you think this might be useful.

In cas= e of problems with the playout, just drop an e-mail to
team@meetecho.c= om.

Cheers,
the Meetecho team

 
Meetecho s.r.l.
Web Conferencing and Collaboration Tools
www.meetecho.com
 
=0A
=0A --_=__=_XaM3_.1333044282.2A.502763.42.8544.52.42.007.799106351-- From pkyzivat@alum.mit.edu Thu Mar 29 12:54:16 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9DF21E801F for ; Thu, 29 Mar 2012 12:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0X3+Jc8F3cb for ; Thu, 29 Mar 2012 12:54:15 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5986D21E801A for ; Thu, 29 Mar 2012 12:54:15 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta12.westchester.pa.mail.comcast.net with comcast id rVm71i00A1vXlb85CXuFkS; Thu, 29 Mar 2012 19:54:15 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta17.westchester.pa.mail.comcast.net with comcast id rXu71i00Y5EhBnE3dXu9fi; Thu, 29 Mar 2012 19:54:13 +0000 Message-ID: <4F74BDDD.1010100@alum.mit.edu> Date: Thu, 29 Mar 2012 21:54:05 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7C@CRPMBOXPRD01.polycom.com> <20120329152600.GB67516@verdi> <92DF9533227FC14F946C7321074B8C9E0110F2A3@XMB-AMS-214.cisco.com> <20120329171843.GC67516@verdi> In-Reply-To: <20120329171843.GC67516@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] audio mixed attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 19:54:16 -0000 I think you all have very clearly demonstrated that just being told that a stream is mixed or not-mixed is insufficient to make any useful decision about what to do with it. Thanks, Paul (as individual) On 3/29/12 7:18 PM, John Leslie wrote: > Espen Berger (espeberg) wrote: >> >> John, you have listed a set of valid acoustical challenges which I >> recognize from our experience. Some of the acoustical challenges will be >> present if a room use 1 or 2+ microphones to record, e.g. when a person >> moves around in the room. > > This is true. > >> We should thrust endpoints that chooses to use multiple microphones for >> capture to do proper audio pre-processing, and keep the audio quality. > > I do not intend anything other than trusting endpoint operators. > But there are inherent differences between single-pickup and multiple > pickups mixed. For many purposes, multiple pickups will be better... > >> I would suggest that we reserve the mixed attribute to scenarios where a >> middle box mix audio captures from different endpoints. > > I don't believe it helpful to define "mixed" based on where the mixing > is done. > > You raise a valid point about "mixing" audio from different rooms. > This, indeed, is something to "hardly-ever" prefer. Thus, to me, I'd > rather it not be an ordinary offer. > > When I describe "mixed" as a warning-label, I did not mean to infer > that "mixed" means "low-quality". > > It sounds to me as if we should seriously consider including a > description of _what_ is being mixed... > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From bruno.chatras@orange.com Fri Mar 30 01:54:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9521F889B for ; Fri, 30 Mar 2012 01:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVBO1GKprMCo for ; Fri, 30 Mar 2012 01:54:08 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id C48F521F888B for ; Fri, 30 Mar 2012 01:54:07 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AAE93107406F for ; Fri, 30 Mar 2012 10:55:40 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A31FB1074055 for ; Fri, 30 Mar 2012 10:55:40 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 10:54:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0E52.A9F73316" Date: Fri, 30 Mar 2012 10:54:06 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214103F3808B@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Boundary between SDP Offer/Answer and CLUE channel Thread-Index: Ac0OUqm0hIhb19FEQn+Q6QxLFyLW+A== From: To: X-OriginalArrivalTime: 30 Mar 2012 08:54:07.0199 (UTC) FILETIME=[AA5DBEF0:01CD0E52] Subject: [clue] Boundary between SDP Offer/Answer and CLUE channel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 08:54:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0E52.A9F73316 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a follow-up to the discussion we had yesterday about the CLUE protocol during the meeting, I would like to verify my understanding of the differences between the proposals that were presented and/or discussed. Does the following text provide an accurate summary of the differences? =20 1) draft-wenger-clue-transport-02 and draft-romanow-clue-sdp-usage-01 =20 Provider advertisement for encoding, consumer encoding configuration: SDP O/A Provider advertisement for media captures: CLUE protocol Consumer selection of media captures: CLUE protocol =20 2) draft-cazeaux-clue-sip-signaling-00 - Solution #1 Provider advertisement for encoding, consumer encoding configuration: SDP O/A Provider advertisement for media captures: SDP O/A Consumer selection of media captures: SDP O/A =20 3) draft-cazeaux-clue-sip-signaling-00 - Solution #2 Provider advertisement for encoding, consumer encoding configuration: SDP O/A Provider advertisement for media captures: SDP O/A Consumer selection of media captures: CLUE protocol =20 4) Alternative mentioned during the discussions Provider advertisement for encoding, consumer encoding configuration: CLUE protocol Provider advertisement for media captures: CLUE protocol Consumer selection of media captures: CLUE protocol SDP O/A used to establish the CLUE channel (if on the media plane) and negotiating the bandwidth for a big pipe =20 I also understood that the above comparison is largely independent from discussions about the pros and cons of the Unidirectional vs. Bidirectional approaches and from the decision to be taken regarding the transport of the CLUE protocol (i.e. signalling vs. media plane). =20 BC =20 ------_=_NextPart_001_01CD0E52.A9F73316 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a follow-up to the discussion = we had yesterday about the CLUE protocol during the meeting, I would like to verify my understanding of the differences between the proposals that were = presented and/or discussed. Does the following text provide an accurate summary of = the differences?

 

1) dra= ft-wenger-clue-transport-02 and dr= aft-romanow-clue-sdp-usage-01

Provider advertisement for = encoding, consumer encoding configuration:  SDP O/A

Provider advertisement for media = captures:  CLUE protocol

Consumer selection of media = captures: CLUE protocol

 

2) draft-cazeaux-clue-sip-signaling-00 – = Solution #1

Provider advertisement for = encoding, consumer encoding configuration:  SDP O/A

Provider advertisement for media = captures:  SDP O/A

Consumer selection of media = captures: SDP O/A

 

3) draft-cazeaux-clue-sip-signaling-00 – = Solution #2

Provider advertisement for = encoding, consumer encoding configuration:  SDP O/A

Provider advertisement for media = captures:  SDP O/A

Consumer selection of media = captures: CLUE protocol

 

4) Alternative mentioned during = the discussions

Provider advertisement for = encoding, consumer encoding configuration:  CLUE = protocol

Provider advertisement for media = captures:  CLUE protocol

Consumer selection of media = captures: CLUE protocol

SDP O/A used to establish the = CLUE channel (if on the media plane) and negotiating the bandwidth for a big = pipe

 

I also understood that the above = comparison is largely independent from discussions about the pros and cons of the = Unidirectional vs. Bidirectional approaches and from the decision to be taken regarding = the transport of the CLUE protocol (i.e. signalling vs. media = plane).

 

BC

 

------_=_NextPart_001_01CD0E52.A9F73316-- From eckelcu@cisco.com Fri Mar 30 06:52:13 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4292421F84FE for ; Fri, 30 Mar 2012 06:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.271 X-Spam-Level: X-Spam-Status: No, score=-9.271 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBxXFXQEVH-6 for ; Fri, 30 Mar 2012 06:52:12 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 666E121F84F3 for ; Fri, 30 Mar 2012 06:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=4714; q=dns/txt; s=iport; t=1333115532; x=1334325132; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=DJ5q5poxTopIPJqe/gO1S0gd5Xn5altIqZ3IZ4bSCBI=; b=gh07x6wo36pRYN7tMMLN8ZPQ+92kIqGr6wpQoTsHRcJ1lzolZCfaZKNV oS4s4oEAEY5flw5Y79Vgw9EB/T5XXUE8jrNsm0g/HM5pD+Q3rpAAuvC/O OtJE0U13nHayersa8uMAn7fRb3PWUE9cDEHpd6sftYACWqH2jOYJ0BNWw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFC5dU+rRDoH/2dsb2JhbABDDrhqgQeCCQEBAQMBAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEEwgah2IEAQufepc6BIp6hTNjBIham0+BaIIwV4E0Bg X-IronPort-AV: E=Sophos;i="4.75,344,1330905600"; d="scan'208";a="35794881" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 30 Mar 2012 13:52:11 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2UDqBP6001963; Fri, 30 Mar 2012 13:52:11 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Mar 2012 06:52:11 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Mar 2012 06:52:08 -0700 Message-ID: In-Reply-To: <4F738516.2000209@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Use of the media capture "composed" attribute Thread-Index: Ac0NpNtfeDOSIx71RAK0snwUtp/U+wA1JTxw References: <4f6a1ef5.6264b40a.1690.5bbb@mx.google.com> <20120321202355.GJ79816@verdi><20120327041255.GB5206@verdi> <4F723272.4040409@alum.mit.edu><44C6B6B2D0CF424AA90B6055548D7A6102FCC17C7B@CRPMBOXPRD01.polycom.com> <4F738516.2000209@alum.mit.edu> From: "Charles Eckel (eckelcu)" To: "Paul Kyzivat" , "Duckworth, Mark" X-OriginalArrivalTime: 30 Mar 2012 13:52:11.0143 (UTC) FILETIME=[4E070970:01CD0E7C] Cc: clue@ietf.org Subject: Re: [clue] Use of the media capture "composed" attribute X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 13:52:13 -0000 Reiterating a comment I made a the mic, I would like to see the addition of semantics that describe the composed/mixed media capture in terms of other media captures, when applicable. I think this would be very useful information for a consumer. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, March 28, 2012 11:40 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: [clue] Use of the media capture "composed" attribute >=20 > I think this further verifies that we need a better explanation of the > intended purpose(s) of these (mixed/composed) attributes so that we can > assess whether we have an actionable definition sufficient to the need. >=20 > Thanks, > Paul >=20 > On 3/28/12 10:52 AM, Duckworth, Mark wrote: > > Paul asked: > >> If mixed and composed aren't intended to drive decisions about > further > >> mixing and composing, then what *are* they for? > > > > I was thinking one other case where the composed attribute would be > used is when a consumer (an endpoint in this case) is choosing which > media captures to receive from a provider. Suppose the provider > advertises capture scene entries that are the same except one of them > has video captures that use composed=3Dtrue, and the other uses > composed=3Dfalse. I think the consumer can reasonably assume the one > with composed=3Dtrue includes more information somehow, possibly with > "Hollywood squares" or picture-in-picture video layout. The consumer > can use this limited information to make a choice. This choice has > nothing to do with whether or not the receiving endpoint is going to > re-compose the images. > > > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >> Paul Kyzivat > >> Sent: Tuesday, March 27, 2012 11:35 PM > >> To: clue@ietf.org > >> Subject: Re: [clue] Use of the media capture "composed" attribute > >> > >> [I don't know if this is as chair or individual. Maybe both.] > >> > >> The discussion of the composed and mixed attributes today exposed a > lot of > >> vagueness about what they mean. I think this needs to be firmed up > >> considerably. > >> > >> Here are some thoughts of my own just to keep the discussion going: > >> > >> Regarding mixed (audio): > >> > >> The fact that an audio capture has mixed content doesn't preclude > mixing it > >> again. But there are properties of it that might make such mixing > >> unsatisfactory. For instance, if AC3 is a mix of (AC1, AC2), then it > is ok to mix > >> AC3 and independent capture AC4. But it would be unwise to mix it > with AC2 > >> again. And it would also be unwise to mix it with AC5 that is itself > a mix of > >> (AC1, AC4). > >> > >> It *might* also be the case that a mix is unwise if it includes > >> (transitively) too many original inputs. > >> > >> Fundamentally it seems like the decision of whether a mix makes > sense > >> requires some complex decision making based on way more data than > >> whether the immediate inputs are themselves mixed or not. > >> > >> Regarding composed (video): > >> > >> This seems potentially more complex. So far the only use I have > heard for > >> this attribute is to drive a decision about whether it makes sense > to compose > >> this capture with others. But I expect that isn't always true > either. You could > >> have one uncomposed capture that shows two people > >> (heads) side by side. You could have another *composed* capture that > also > >> shows two people in independently side by side each inside a frame, > that > >> were assembled from other captures. (Would anyone argue that this > isn't > >> composed?) But I can't see why it would be any more or less > desirable to > >> compose one of these captures than another. > >> > >> Again it seems like you need more information about what has been > >> composed, and at what scale (and maybe position) before you can make > a > >> decision about whether it makes sense to compose it. And then that > may > >> also depend on *how* you want to compose it. > >> > >> If mixed and composed aren't intended to drive decisions about > further > >> mixing and composing, then what *are* they for? > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue