From pkyzivat@alum.mit.edu Wed May 1 07:13:23 2013 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 5505E21F992B for ; Wed, 1 May 2013 07:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 0bmrl8iim5be for ; Wed, 1 May 2013 07:13:17 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 6351821F9914 for ; Wed, 1 May 2013 07:13:16 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta14.westchester.pa.mail.comcast.net with comcast id Wd8E1l0011GhbT85EeDFL7; Wed, 01 May 2013 14:13:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id WeDF1l00G3ZTu2S3TeDF2r; Wed, 01 May 2013 14:13:15 +0000 Message-ID: <518122FA.9070504@alum.mit.edu> Date: Wed, 01 May 2013 10:13:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D65CECE6@CRPMBOXPRD07.polycom.com> <51807349.9080906@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D677AEB5@CRPMBOXPRD07.polycom.com> <51808283.2070101@nteczone.com> In-Reply-To: <51808283.2070101@nteczone.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367417595; bh=tDACa5Wbk94wKcAiLWijseSmrPfS/Y4Zx0bPP/+22b8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GqPMxmrDVKMrudNrAp69vXy24gs6547LL3DSeFikrFsephJqMiS0+YtelFISBRCXt tE6xGOb7j+9sbIh/euNsnQ653fRGYvMCPXt6KmLYMFoU1Jz399+n6zy23QAtx88bKC 4v2qKTawUFW+nFL5PhnJjCCC7BhGLzzSnMDXbkyvQz4N9QEYtYbIezu07p+xfdLeh9 jj1+jPRlurS+iI3B4qNgPRAmz93bunTSScC0fu5tdEeGYTs6D2Tz1qqAVanFGhCUOh /pqM3XFdws0X8XbVC9NFv14hB3TlmafH/ehjNvuHHkO5pHOky1aIImuu499vaJZlIi 3W4ltbSDfL63Q== Subject: Re: [clue] usage of Conference Roles - valid only with switched captures? 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, 01 May 2013 14:13:23 -0000 On 4/30/13 10:48 PM, Christian Groves wrote: > I guess the CLUE role "speaker" would denote > Speaker/Presentor as the person presenting material. The "current > speaker" determined by audio energy etc would be handled by BFCP (or > similar). +1 "Speaker" as a role has a very different meaning from "current speaker" / "loudest speaker". Thanks, Paul From Mark.Duckworth@polycom.com Wed May 1 12:43:19 2013 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 6C52221F998A for ; Wed, 1 May 2013 12:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 xQRRoIwziOAU for ; Wed, 1 May 2013 12:43:15 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3032F21F96FA for ; Wed, 1 May 2013 12:43:15 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 1 May 2013 12:43:14 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 1 May 2013 12:43:13 -0700 Thread-Topic: [clue] usage of Conference Roles - valid only with switched captures? Thread-Index: Ac5Gdg6179PNuSneSoenn2w89OG32AALY40A Message-ID: <49E45C59CA48264997FEBFB29B6BC2D677B28E@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D65CECE6@CRPMBOXPRD07.polycom.com> <51807349.9080906@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D677AEB5@CRPMBOXPRD07.polycom.com> <51808283.2070101@nteczone.com> <518122FA.9070504@alum.mit.edu> In-Reply-To: <518122FA.9070504@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] usage of Conference Roles - valid only with switched captures? 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, 01 May 2013 19:43:19 -0000 Yes, that makes more sense to me too. But that isn't what I understood fro= m draft-groves-clue-capture-attr-01. Since Christian is working on a new d= raft related to roles, I think we should wait for that before adding Role a= ttributes to the framework. In the meantime, I can add the other attributes from that current draft int= o the framework. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, May 01, 2013 10:13 AM > To: clue@ietf.org > Subject: Re: [clue] usage of Conference Roles - valid only with switched > captures? >=20 > On 4/30/13 10:48 PM, Christian Groves wrote: >=20 > > I guess the CLUE role "speaker" would denote Speaker/Presentor as the > > person presenting material. The "current speaker" determined by audio > > energy etc would be handled by BFCP (or similar). >=20 > +1 >=20 > "Speaker" as a role has a very different meaning from "current speaker" > / "loudest speaker". >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed May 1 13:57:50 2013 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 B99F121F9AB5 for ; Wed, 1 May 2013 13:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 hEcwqCkTUin0 for ; Wed, 1 May 2013 13:57:45 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE9E21F986C for ; Wed, 1 May 2013 13:56:32 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 1 May 2013 13:56:31 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 1 May 2013 13:56:29 -0700 Thread-Topic: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries Thread-Index: Ac5GGNzch2EVCRxXSC+zkC6aEiQnQgAlNO3w Message-ID: <49E45C59CA48264997FEBFB29B6BC2D677B323@CRPMBOXPRD07.polycom.com> References: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> <517FF52C.204@alum.mit.edu> <51807583.1010501@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D677AEB7@CRPMBOXPRD07.polycom.com> <518086A8.9000009@nteczone.com> In-Reply-To: <518086A8.9000009@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] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries 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, 01 May 2013 20:57:50 -0000 > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Tuesday, April 30, 2013 11:06 PM > To: Duckworth, Mark > Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and > Capture Scene Entries > >> [CNG] In some respects not having the CS, CSE in an STS mirrors a > >> configure response in that it only lists captures. However there > >> appears to be a problem with a configure when having to return CSE > parameters. > >> If a consumer can "choose" attribute values what it mean for STSs? > >> Does the value setting have an effect on what media capture > >> combination can be supported in a capture? > > [Duckworth, Mark] I don't understand the question. What do you mean by > "what media capture combination can be supported in a capture"? I'll loo= k > for the Capture Scene Entry attribute question and respond separately, I > don't see how it is related to this thread. > [CNG] For example: We have a CSE attribute of Scene-Switch-Policy which > allows a provider to select the value. What I was wondering is if this af= fects > what media captures are mentioned in the STS? For switching I might be ab= le > to support a different number captures than say a segment switch. If a > consumer advertises an STS with a CSE that is effectively "variable" what > could this mean? We do say that all captures within an CSE must be able t= o be > sent together so it may not be a problem. [Duckworth, Mark] I don't see a problem. If a Provider really wants to ex= press a different Simultaneous Transmission Set depending on the type of Sc= ene-Switch-Policy, then the provider can advertise separate Capture Scene E= ntries with separate Media Captures, where each Capture Scene Entry has a d= ifferent Scene-Switch-Policy. And also use multiple Simultaneous Transmiss= ion Sets to express the options for what it can send simultaneously. Mark From prvs=3834f4ee55=christer.holmberg@ericsson.com Thu May 2 03:41:40 2013 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 4A06C21F98CD for ; Thu, 2 May 2013 03:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 awSkxWcWZyZ5 for ; Thu, 2 May 2013 03:41:34 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 143F321F9612 for ; Thu, 2 May 2013 03:40:20 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-04-518242900755 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BB.9F.32006.09242815; Thu, 2 May 2013 12:40:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Thu, 2 May 2013 12:40:16 +0200 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries Thread-Index: Ac5FojlN3bf5TUXZQr2IHkPIJ+y6/wBfqM7Q Date: Thu, 2 May 2013 10:40:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C369867@ESESSMB209.ericsson.se> References: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvre4Ep6ZAgzMHrCz2n7rMbLHuyFNm ByaPJUt+Mnm8eKAUwBTFbZOUWFIWnJmep2+XwJ3R9eo8S8Fm/oqlS64zNjCu5eli5OSQEDCR 6J1zkwnCFpO4cG89WxcjF4eQwGFGiYM321ghnMWMEi8mLmXpYuTgYBOwkOj+pw3SICIQKrF6 5iYWEFtYIEZixof7jBDxWIk7n9+wQthGEodnzwOLswioSFx9+hFsGa+Ar8TiQ9vYQGwhIHt6 +yWwOZwCfhJrv10HizMCHfT91BqwemYBcYlbT+ZDHSogsWTPeWYIW1Ti5eN/rBC2osTV6cuh 6vUkbkydwgZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMnvdxo EyMwFg5u+a26g/HOOZFDjNIcLErivMlcjYFCAumJJanZqakFqUXxRaU5qcWHGJk4OEEEl1QD o/O52C35BaWPXLe6h3YuEGzcYs5S6hjiI/5AaP6C47KsYspLZmi/3pHUzjq9XPOTdPhKY4/t Z9cxbjV09ngz49wOya8zXnx13stxITrxmUu8HfPP1q0zdrcHna0RFdrw50dzqamXy4r9idnG P14EN6jN5H1blbnB0mX78VUTfvsX1/vd4tW0UmIpzkg01GIuKk4EADxrsypYAgAA Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries 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, 02 May 2013 10:41:40 -0000 Hi, > This is a follow up to an action item from IETF-86.=A0 I said I would pro= pose text based on the discussion to allow a=20 > Media Provider to represent Simultaneous Transmission Sets in terms of Ca= pture Scenes and Capture Scene=20 > Entries.=A0 Currently the framework says a Simultaneous Transmission Set = is a set of Media Captures of a particular media type. > > =3D=3D=3D begin proposed new paragraph to add near end of section 6.3 =3D= =3D=3D > For shorthand convenience, a Provider may describe a Simultaneous Transmi= ssion Set in terms of Capture Scene=20 > Entries and Capture Scenes.=A0 If a Capture Scene Entry is included in a = Simultaneous Transmission Set, then all Media Captures in the Capture Scene= Entry are included in the Simultaneous Transmission Set.=A0 If a Capture S= cene is included > in a Simultaneous Transmission Set, then all its Capture= Scene Entries (of the corresponding media type) are included=20 > in the Simultaneous Transmission Set.=A0 The end result reduces to a set = of Media Captures in any case. > =3D=3D=3D end proposed new paragraph to add near end of section 6.3 =3D= =3D=3D > > I suggest we do not make this change, and instead just describe a Simulta= neous Transmission Set as a set of Media Captures.=A0 I think=20 > allowing the additional ways to represent the set adds complication witho= ut adding value.=A0 A Media Consumer that wants to use=20 > simultaneous sets would have more work to do to parse out the contents of= the set. > > Your thoughts? I disagree with your suggestion. We have had long discussions about this, and if I remember correctly the ou= tcome was that we will allow the STS to contain media captures, CSEs and CS= s. With only allowing media captures, the consumer will have to do work in ord= er to figure out which ones have spatial relationship etc, while a CSE prov= ides that information implicitly. Regards, Christer From pkyzivat@alum.mit.edu Thu May 2 08:09:53 2013 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 61B5121F8E2C for ; Thu, 2 May 2013 08:09:53 -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.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 4CC2ziKlx6iL for ; Thu, 2 May 2013 08:09:47 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF8F21F8CEC for ; Thu, 2 May 2013 08:09:46 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta15.westchester.pa.mail.comcast.net with comcast id WzJr1l0021ap0As5F39hte; Thu, 02 May 2013 15:09:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id X39h1l0053ZTu2S3i39hTW; Thu, 02 May 2013 15:09:41 +0000 Message-ID: <518281B4.5000201@alum.mit.edu> Date: Thu, 02 May 2013 11:09:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C369867@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C369867@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1367507381; bh=GCAgcgQdAIQCt2N3rubL7u0MDkXSZgvfImofRBQE5f8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=UYXBbK1ZzvaNnJgZxmco9j+VZIsYLKKgLuRT/1qRlxZ28IWXsKpawu6Ns6HFU21Au u0vVWAfb/Pab0upuX2l8HeDGqpWUz3LAXhF8QIclhgp055LbLrjgM0ojtmk1jFdKlY p7KsrVlDaVPdu6ZPLqvRlL71GairfCVrJffEwnL0ha40eNa+IpOTyEGAN6OMh5G8YV qwafy+Khax9b0fBCu6XZRe75Vq0aoyi/fNlOGf8h7h7NEhKm3RmCnLSByT1MWDJVx0 zDgyDBcKC6mblWMxSJD6q8FblsOn0IrdRi0r+gybaKlWxeAwrEcVaMZhu5Hd6OXIGk 7F7ZgZ8+meCTw== Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries 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, 02 May 2013 15:09:53 -0000 On 5/2/13 6:40 AM, Christer Holmberg wrote: > Hi, > >> This is a follow up to an action item from IETF-86. I said I would propose text based on the discussion to allow a >> Media Provider to represent Simultaneous Transmission Sets in terms of Capture Scenes and Capture Scene >> Entries. Currently the framework says a Simultaneous Transmission Set is a set of Media Captures of a particular media type. >> >> === begin proposed new paragraph to add near end of section 6.3 === >> For shorthand convenience, a Provider may describe a Simultaneous Transmission Set in terms of Capture Scene >> Entries and Capture Scenes. If a Capture Scene Entry is included in a Simultaneous Transmission Set, then all Media Captures in the Capture Scene Entry are included in the Simultaneous Transmission Set. If a Capture Scene is included > in a Simultaneous Transmission Set, then all its Capture Scene Entries (of the corresponding media type) are included >> in the Simultaneous Transmission Set. The end result reduces to a set of Media Captures in any case. >> === end proposed new paragraph to add near end of section 6.3 === >> >> I suggest we do not make this change, and instead just describe a Simultaneous Transmission Set as a set of Media Captures. I think >> allowing the additional ways to represent the set adds complication without adding value. A Media Consumer that wants to use >> simultaneous sets would have more work to do to parse out the contents of the set. >> >> Your thoughts? > > I disagree with your suggestion. > > We have had long discussions about this, and if I remember correctly the outcome was that we will allow the STS to contain media captures, CSEs and CSs. > With only allowing media captures, the consumer will have to do work in order to figure out which ones have spatial relationship etc, while a CSE provides that information implicitly. I don't have a strong opinion on this, either way. But I find it silly to base the decision on whether more work must be done by the provider or the consumer. From a computation perspective it is insignificant. From a programming perspective for the developer it is a few minutes work, either in the provider code or the consumer code. And most implementations will be both provider and consumer, so they have to write the code anyway. One might argue that having this ability will make advertisements smaller. In indeed might, but again the difference is going to be insignificant in any practical case. IMO that leaves a few criteria to use to decide: PRO: make examples and use cases easier to read and write CON: minimize the complexity of the data model schema Thanks, Paul (as individual) From prvs=4835715ece=christer.holmberg@ericsson.com Fri May 3 03:05:55 2013 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 C3EF421F95DC for ; Fri, 3 May 2013 03:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 reYVOy2K8MXS for ; Fri, 3 May 2013 03:05:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1E36621F91C9 for ; Fri, 3 May 2013 03:05:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-75-51838bfb86ab Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id CB.64.01956.BFB83815; Fri, 3 May 2013 12:05:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Fri, 3 May 2013 12:05:47 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries Thread-Index: Ac5FojlN3bf5TUXZQr2IHkPIJ+y6/wBfqM7QAAVcVAAAK6v+YA== Date: Fri, 3 May 2013 10:05:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C36B30B@ESESSMB209.ericsson.se> References: <49E45C59CA48264997FEBFB29B6BC2D65CE8AE@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C369867@ESESSMB209.ericsson.se> <518281B4.5000201@alum.mit.edu> In-Reply-To: <518281B4.5000201@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUyM+Jvre7v7uZAg0uXzSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApitsmKbGkLDgzPU/fLoE7Y8HeTewFtyQr1i1vYG5gPCTSxcjJISFg IvFnwjpmCFtM4sK99WxdjFwcQgKHGSV2PP7KDuEsZpT4ueUjkMPBwSZgIdH9TxukQUTAU2LH xylgzcICMRIzPtxnhIjHStz5/IYVwnaSeDpvDxuIzSKgIvFx4UQmEJtXwFdiTvs5Foj5mxkl rlw/xQKS4BTQkbjQ1w82iBHoou+n1oA1MAuIS9x6Mp8J4lIBiSV7zkNdLSrx8vE/VghbUeLq 9OVQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmT Xm6+iREYDwe3/DbYwbjpvtghRmkOFiVx3mSuxkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCC S6qB0UbhCXPXuW+Vsmcf92xJNW2vLnx/rPn2FX6DTfJB5dPPvLXP7ohRFPlz7I8i8+wXr4z9 XT36miouJR7O+6Emrd8/N2/z/5JNqv/lL5X9Xp78c3Lr49JDl3/sti5PvPFbQunLr/7dz7tY T1m/2HS9XzjuyKt+iX1G631ylGYKzLBwtztaU1K2S4mlOCPRUIu5qDgRAMlXCQdaAgAA Subject: Re: [clue] Simultaneous Sets in terms of Capture Scenes and Capture Scene Entries 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, 03 May 2013 10:05:55 -0000 Hi, >>> This is a follow up to an action item from IETF-86. I said I would=20 >>> propose text based on the discussion to allow a Media Provider to=20 >>> represent Simultaneous Transmission Sets in terms of Capture Scenes and= Capture Scene Entries. Currently the=20 >>> framework says a Simultaneous Transmission Set is a set of Media Captur= es of a particular media type. >>> >>> =3D=3D=3D begin proposed new paragraph to add near end of section 6.3 = =3D=3D=3D=20 >>> For shorthand convenience, a Provider may describe a Simultaneous=20 >>> Transmission Set in terms of Capture Scene Entries and Capture=20 >>> Scenes. If a Capture Scene Entry is included in a Simultaneous Transmi= ssion Set, then all Media Captures in the=20 >>> Capture Scene Entry are included in the Simultaneous Transmission Set. = If a Capture Scene is included=20 >>> in a Simultaneous Transmission Set, then all its Capture Scene Entries = (of the corresponding media type) are included=20 >>> in the Simultaneous Transmission Set. The end result reduces to a set = of Media Captures in any case. >>> =3D=3D=3D end proposed new paragraph to add near end of section 6.3 =3D= =3D=3D >>> >>> I suggest we do not make this change, and instead just describe a=20 >>> Simultaneous Transmission Set as a set of Media Captures. I think=20 >>> allowing the additional ways to represent the set adds complication wit= hout adding value. A Media Consumer that wants to use simultaneous sets wo= uld have more work to do to parse out the contents of the set. >>> >>> Your thoughts? >> >> I disagree with your suggestion. >> >> We have had long discussions about this, and if I remember correctly the= outcome was that we will allow the STS to contain media captures, CSEs and= CSs. >> With only allowing media captures, the consumer will have to do work in = order to figure out which ones have spatial relationship etc, while a CSE p= rovides that information implicitly. > > I don't have a strong opinion on this, either way. > > But I find it silly to base the decision on whether more work must be don= e by the provider or the consumer. From a computation perspective it is=20 > insignificant. From a programming perspective for the developer it is a f= ew minutes work, either in the provider code or the consumer code.=20 > And most implementations will be both provider and consumer, so they have= to write the code anyway. > > One might argue that having this ability will make advertisements smaller= . In indeed might, but again the difference is going to be insignificant in= any practical case. It is not about the code. But, in many systems the provided, and the consumed, CSE will always be the= same - especially when more "low end" devices are used. So, instead of hav= ing to always compute the same stuff, simply signal the CSE. The important thing, as we discussed in Orlando, is to make sure that we ge= t the semantics correct, ie to make sure it is clear what it means when e.g= . a media capture is advertised individually, and part of a CSE. Etc. So, unless there is a technical problem why it won't work, I don't think we= shall go back on agreements that we have managed to reach. Regards, Christer From mary.ietf.barnes@gmail.com Fri May 3 09:57:27 2013 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 3A39321F9601 for ; Fri, 3 May 2013 09:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.199 X-Spam-Level: X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 YqN9SMRBBSMB for ; Fri, 3 May 2013 09:57:23 -0700 (PDT) Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com [209.85.128.41]) by ietfa.amsl.com (Postfix) with ESMTP id EF40E21F9A53 for ; Fri, 3 May 2013 08:50:08 -0700 (PDT) Received: by mail-qe0-f41.google.com with SMTP id b10so981572qen.0 for ; Fri, 03 May 2013 08:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=lHGP20yR8H+xBokK5kxXwtPjpvHYc23WF4hxzvcIn6U=; b=KVj+glSt4qFri4cRxBEX/4IjwuQs9HnxQ4yZI9SCsjovwMBZ4bSTVTS6rZIyCjNIf8 13NUZLJrCZmOFRFuuoeL36RtCidLEwC7KeUcxa8Mcwros8t4/xZxmfTmvoR5MFKjFe7P y0x08Z6fySZ9JIewt9yJ5IzqfAwhneGqiimhKGFPGqzaaX7nLYD8WpN+akfH19NOrXl2 7a9wMzjzAzV13JSWt45YglN868k6WCROZE8Bdj1xOuA+UaLuJ/XQWtmwtPanFq89LqIj bnfMNYMir5CvXC6KNZNzMbkp/y6nQedt78RBfg2dwUU4ZpD8El1MdXRd01oChVSwGzcs Bl+Q== MIME-Version: 1.0 X-Received: by 10.224.147.83 with SMTP id k19mr13298032qav.72.1367596208317; Fri, 03 May 2013 08:50:08 -0700 (PDT) Received: by 10.49.117.163 with HTTP; Fri, 3 May 2013 08:50:08 -0700 (PDT) In-Reply-To: References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> Date: Fri, 3 May 2013 10:50:08 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.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: Fri, 03 May 2013 16:57:27 -0000 It would be good for folks to review this, in particular the parts describing the legacy interworking. Mary. ---------- Forwarded message ---------- From: Justin Uberti Date: Fri, May 3, 2013 at 1:08 AM Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: "rtcweb@ietf.org" , "mmusic@ietf.org" Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each. Hopefully this will make discussion of this topic easier. ---------- Forwarded message ---------- From: Date: Thu, May 2, 2013 at 10:46 PM Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt To: Justin Uberti A new version of I-D, draft-uberti-rtcweb-plan-00.txt has been successfully submitted by Justin Uberti and posted to the IETF repository. Filename: draft-uberti-rtcweb-plan Revision: 00 Title: Plan B: a proposal for signaling multiple media sources in WebRTC. Creation date: 2013-05-03 Group: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt Status: http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan Htmlized: http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00 Abstract: This document explains how multiple media sources can be signaled in WebRTC using SDP, in a fashion that avoids many common problems and provides a simple control surface to the receiver. The IETF Secretariat _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From fandreas@cisco.com Wed May 8 19:00:28 2013 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 1272321F9113 for ; Wed, 8 May 2013 19:00:28 -0700 (PDT) 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=[AWL=-0.000, 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 FIXr2bVRt9X4 for ; Wed, 8 May 2013 19:00:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6A43621F90C3 for ; Wed, 8 May 2013 19:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5534; q=dns/txt; s=iport; t=1368064823; x=1369274423; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=B3B9byhcF9psCctoqbDknGSpwKqnmSt4eim/xGFyIhc=; b=BJ/WNz3d22zS8Wwk9KL2y0imBe/n2DSaQMXmG9Llru3KfeWLg4CA19lN c6YSB5dhDFBvoCWO0y4dyj1t+nKcy3TLdPS+CToWw5YIkt/79j1O1/SAa RWx4fp/qiJwqOYf6imm4ZgeCLzyRIetDc7CjskxlJjRUV+PYoaObwqgb9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHAMACi1GtJXHA/2dsb2JhbABSgwc3iRq2FnsWdIIfAQEBBAEBAWsKDQQcAwECChYPCQMCAQIBFSYCCBMGAgEBBYgDDMEwjxcYBoNPA5cskTWDKyA X-IronPort-AV: E=Sophos;i="4.87,638,1363132800"; d="scan'208,217";a="207925701" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 09 May 2013 02:00:23 +0000 Received: from rtp-fandreas-8713.cisco.com (rtp-fandreas-8713.cisco.com [10.117.7.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4920MBh007208 for ; Thu, 9 May 2013 02:00:22 GMT Message-ID: <518B0336.4010407@cisco.com> Date: Wed, 08 May 2013 22:00:22 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: clue@ietf.org References: <518B0290.1070509@cisco.com> In-Reply-To: <518B0290.1070509@cisco.com> X-Forwarded-Message-Id: <518B0290.1070509@cisco.com> Content-Type: multipart/alternative; boundary="------------070905030002000200060405" X-Mailman-Approved-At: Wed, 08 May 2013 21:21:52 -0700 Subject: [clue] Fwd: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013 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, 09 May 2013 02:00:28 -0000 This is a multi-part message in MIME format. --------------070905030002000200060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013 Date: Wed, 8 May 2013 21:57:36 -0400 From: Flemming Andreasen To: mmusic CC: rai-ads , IESG Secretary Greetings This is to announce a virtual interim meeting for the MMUSIC Working Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: We are currently also considering having a physical interim meeting the week of June 24th, likely on the US West Coast. We will await the outcome of the virtual interim meeting before making a decision on this but wanted to give people a heads-up for now. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------070905030002000200060405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI


-------- Original Message --------
Subject: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013
Date: Wed, 8 May 2013 21:57:36 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org>
CC: rai-ads <rai-ads@tools.ietf.org>, IESG Secretary <iesg-secretary@ietf.org> 


Greetings

This is to announce a virtual interim meeting for the MMUSIC Working 
Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am 
Pacific Time. The goal of this meeting is to come to a resolution on the 
so-called "Plan A" or "Plan B" approach related to SDP signaling needed 
by RTCWeb, CLUE, etc.  (i.e. do we have potentially lots of "m=" lines 
or very few "m=" lines and to what extent is there sub-negotation and 
signaling at the SSRC level).

A more detailed agenda and logistics will be sent out separately. For 
now, people should take a close look at the following two drafts:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt

You may also want to look at 
http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt


Thanks

-- Ari & Flemming (MMUSIC co-chairs)


PS: We are currently also considering having a physical interim meeting 
the week of June 24th, likely on the US West Coast. We will await the 
outcome of the virtual interim meeting before making a decision on this 
but wanted to give people a heads-up for now.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--------------070905030002000200060405-- From mary.ietf.barnes@gmail.com Tue May 14 13:41:22 2013 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 10D8D21F8F6E for ; Tue, 14 May 2013 13:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 DJQ-kjjeQbt4 for ; Tue, 14 May 2013 13:41:21 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5905C21F8F43 for ; Tue, 14 May 2013 13:41:21 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id bs12so717968qab.15 for ; Tue, 14 May 2013 13:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=5odF6ZoeNYivhqVKiBz8rjs7CKPe8juEfD6q6mvYwjI=; b=AJ4QmXycwsvd8MEddfop+Ib6N8LF9Fv4fT58sS4qhzmtjTCox9+1vI/CDoCBTtsTsK e/QtihEuMCMcMyIn8VcUv8q6tP0FGa6fxguVBGNvdSCyVyb9RZG6DeZhVxMzEr45qgio nYu4Su7d1J5qblo77SgN9gPgkr3SFua+0bPgwTK+8tfpSr1zImhUBoWA5Dm273qMgCxo 7Qlmi/HC4pySNVGdCs24W4SSokCF4avLyVpP825OHQbxonCgbx0ZIZd73gVXfZAJhRfd ZiU8c1+pCr9y6j3NtVid17m0UDWJKyzYXUpyFCuShNgqXRKLER9BxUvAPzq9cmJt161f 3Fpg== MIME-Version: 1.0 X-Received: by 10.229.90.5 with SMTP id g5mr2362746qcm.26.1368564080779; Tue, 14 May 2013 13:41:20 -0700 (PDT) Received: by 10.49.116.172 with HTTP; Tue, 14 May 2013 13:41:20 -0700 (PDT) Date: Tue, 14 May 2013 15:41:20 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Reminder: CLUE WG Interim Meeting - May 21st, 2013 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, 14 May 2013 20:41:22 -0000 A reminder that we have scheduled a virtual (Webex) interim meeting for CLUE WG for May 21st, 2013 starting at 9am central. The Webex details are available here and on the wiki: http://www.ietf.org/mail-archive/web/clue/current/msg02547.html An agenda has been posted to the interim proceedings: http://www.ietf.org/proceedings/interim/2013/05/21/clue/proceedings.html The presentations will also be available there. At this time, there are no revised documents. Any document updates should be done no later than 5pm Pacific on Friday, May 17th. Presentations should be sent to the chairs no later than noon Pacific on Monday, May 20th. Also, an important reminder that there will be an MMUSIC interim meeting next week as well: http://www.ietf.org/mail-archive/web/clue/current/msg02569.html I strongly encourage CLUE folks to attend that session, as well. There has been lots of discussion on both the MMUSIC and RTCWEB WG mailing lists with regards to handling multiple media sources, including discussion of the following drafts from the RTCWEB WG: http://www.ietf.org/id/draft-uberti-rtcweb-plan-00.txt http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://datatracker.ietf.org/doc/draft-roach-rtcweb-glareless-add/ Folks that are not subscribed to the RTCWEB mailing list should at least review the discussion threads for those documents. Regards, Mary CLUE WG co-chair From internet-drafts@ietf.org Thu May 16 13:39:08 2013 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 B052F11E8162; Thu, 16 May 2013 13:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-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 8QzmdOLNyVsJ; Thu, 16 May 2013 13:39:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5671B11E8142; Thu, 16 May 2013 13:39:08 -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.45 Message-ID: <20130516203908.5309.17627.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2013 13:39:08 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-10.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: Thu, 16 May 2013 20:39:08 -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 tElepres= ence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-10.txt Pages : 48 Date : 2013-05-16 Abstract: This document offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mary.ietf.barnes@gmail.com Tue May 21 16:25:15 2013 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 CAB9A21F915C for ; Tue, 21 May 2013 16:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 Kvwg6HO7TJTs for ; Tue, 21 May 2013 16:25:13 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFD821F911B for ; Tue, 21 May 2013 16:25:12 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id j11so732949qag.15 for ; Tue, 21 May 2013 16:25:11 -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; bh=9cJxnZlpFbSKMkQ74wzdxsg/oi5xpVT2w6C6IFxXlaE=; b=ba99a7XVydkvptYmKN31YIBDQuKs//I/kePL+0AidyPzGGQCLEoZzzcAP8IEkKjVLg TFCaqQcHi5LdBw99eyW5d3AMr/xUilVCRlB9annQsVbb5nuRCGhZcgv0IuV8HzJPjGXN zFngfa5nU8P4C47BqFl/+LgXYZrGcm2sOC4Bu5Kk0qq+L0TsUzh3Gs/7cct9sI4tkjFX E8YmJuU6rkGWYrwtng0MsVmp7p68ivcNuz1wn+sbrUvBx0LH3xnsCmvYpIU6tW7RvZcs su+UpIAGrOf0fw5jw1LBmNp+0hDY88lywXZJ/0Xm26PuG8kIiquhAeAVh+NnYWkASTnk Dkhg== MIME-Version: 1.0 X-Received: by 10.224.59.200 with SMTP id m8mr4632003qah.43.1369178711725; Tue, 21 May 2013 16:25:11 -0700 (PDT) Received: by 10.49.94.14 with HTTP; Tue, 21 May 2013 16:25:11 -0700 (PDT) In-Reply-To: <518B0336.4010407@cisco.com> References: <518B0290.1070509@cisco.com> <518B0336.4010407@cisco.com> Date: Tue, 21 May 2013 18:25:11 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf3074d5c4bf1ece04dd42c27a Subject: Re: [clue] Fwd: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013 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, 21 May 2013 23:25:15 -0000 --20cf3074d5c4bf1ece04dd42c27a Content-Type: text/plain; charset=ISO-8859-1 For folks that were planning to attend this interim, the agenda has changed as they couldn't get the principals for the Plan A versus Plan B discussion. They will be discussing BUNDLE: http://www.ietf.org/mail-archive/web/mmusic/current/msg11102.html Note, they are also trying to organize another session to discuss the A vs B, so folks may want to respond to this poll: http://www.ietf.org/mail-archive/web/mmusic/current/msg11115.html I still encourage folks to review those drafts and comment on the mailing list(s). Note, that most of the A vs B discussion has been on the RTCWEB mailing list. http://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html Regards, Mary. On Wed, May 8, 2013 at 9:00 PM, Flemming Andreasen wrote: > FYI > > > -------- Original Message -------- Subject: [MMUSIC] MMUSIC Virtual > Interim Meeting Announcement for May 23, 2013 Date: Wed, 8 May 2013 > 21:57:36 -0400 From: Flemming Andreasen To: > mmusic CC: rai-ads > , IESG Secretary > > > Greetings > > This is to announce a virtual interim meeting for the MMUSIC Working > Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am > Pacific Time. The goal of this meeting is to come to a resolution on the > so-called "Plan A" or "Plan B" approach related to SDP signaling needed > by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines > or very few "m=" lines and to what extent is there sub-negotation and > signaling at the SSRC level). > > A more detailed agenda and logistics will be sent out separately. For > now, people should take a close look at the following two drafts: > http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt > http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt > > You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt > > > Thanks > > -- Ari & Flemming (MMUSIC co-chairs) > > > PS: We are currently also considering having a physical interim meeting > the week of June 24th, likely on the US West Coast. We will await the > outcome of the virtual interim meeting before making a decision on this > but wanted to give people a heads-up for now. > > _______________________________________________ > mmusic mailing listmmusic@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --20cf3074d5c4bf1ece04dd42c27a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
For folks that were planning to attend this interim, the a= genda has changed as they couldn't get the principals for the Plan A ve= rsus Plan B discussion. =A0They will be discussing BUNDLE:

Note, they are also trying to organize another se= ssion to discuss the A vs B, so folks may want to respond to this poll:
=

I still encourage folks to review those drafts an= d comment on the mailing list(s). Note, that most of the A vs B discussion = has been on the RTCWEB mailing list.=A0

Regards,
Mary.


On Wed, May 8, 2013 = at 9:00 PM, Flemming Andreasen <fandreas@cisco.com> wrote:<= br>
=20 =20 =20
FYI


-------- Original Message --------
Subject: [MMUSIC] MMUSIC Virtual Interim Meeting Announcement for May 23, 2013
Date: Wed, 8 May 2013 21:57:36 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: mmusic <mmusic@ietf.org>
CC: rai-ads <rai-ads@tools.ietf.org>, IESG Secretary = <iesg-secretary@ietf.org> 


Greetings

This is to announce a virtual interim meeting for the MMUSIC Working=20
Group to take place on Thursday, May 23rd, from 7:00 am - 10:00 am=20
Pacific Time. The goal of this meeting is to come to a resolution on the=20
so-called "Plan A" or "Plan B" approach related to SDP =
signaling needed=20
by RTCWeb, CLUE, etc.  (i.e. do we have potentially lots of "m=3D"=
; lines=20
or very few "m=3D" lines and to what extent is there sub-negotati=
on and=20
signaling at the SSRC level).

A more detailed agenda and logistics will be sent out separately. For=20
now, people should take a close look at the following two drafts:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

http://www.ietf.org/internet-drafts/draft-uberti-rtc=
web-plan-00.txt

You may also want to look at=20
http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-0=
0.txt


Thanks

-- Ari & Flemming (MMUSIC co-chairs)


PS: We are currently also considering having a physical interim meeting=20
the week of June 24th, likely on the US West Coast. We will await the=20
outcome of the virtual interim meeting before making a decision on this=20
but wanted to give people a heads-up for now.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
=
https://www.ietf.org/mailman/listinfo/mmusic



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


--20cf3074d5c4bf1ece04dd42c27a-- From Christian.Groves@nteczone.com Tue May 21 19:53:18 2013 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 9B3C721F933B for ; Tue, 21 May 2013 19:53:18 -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=[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 bf2zB0Zko06d for ; Tue, 21 May 2013 19:53:17 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 70FBD21F92E8 for ; Tue, 21 May 2013 19:53:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcBABkynFF20Rdu/2dsb2JhbAANTcZNbYJYERslPRYYAwIBAgFLDQgBAbE3klGSdQOsGQ Received: from ppp118-209-23-110.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.23.110]) by ipmail05.adl6.internode.on.net with ESMTP; 22 May 2013 12:23:15 +0930 Message-ID: <519C3316.7020707@nteczone.com> Date: Wed, 22 May 2013 12:53:10 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Label attribute for CLUE 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, 22 May 2013 02:53:18 -0000 Hello We discussed in yesterday's virtual interim meeting about the use of the a=label: in the signalling flows. My concern is with regards to the scope of the label attribute. Section 4/RFC4574 says "The new attribute can be attached to 'm' lines in multiple SDP documents allowing the application to logically group the media streams across SDP sessions when necessary." Considering an MCU case my understanding is that any identities used in CLUE only have scope to a particular advertisement. i.e. the MCU can use the same Scene and capture ids in Advertisements to different endpoints. If label has the scope over multiple SDP sessions does this mean that the CLUE strings used with label would have to be unique across all SDP sessions in a MCU or gateway? Also RFC4796 section 3 on the Content Attribute indicates that a new attribute was required because of a problem of backward compatibility. Would this apply to a clue attribute also? For example if the endpoint uses BFCP which uses label it would have to make sure labels for CLUE didn't overlap. Also existing BFCP processing would just see a label string. It wouldn't know that a=label:CLUE1 is not to be considered. For CLUE I think we need to look at defining a specific SDP attribute for this m-line -> encoding mapping. Regards, Christian From pkyzivat@alum.mit.edu Wed May 22 07:51:59 2013 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 B732B21F9403 for ; Wed, 22 May 2013 07:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 qvA-qb1wBeSN for ; Wed, 22 May 2013 07:51:55 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id E4D5921F8935 for ; Wed, 22 May 2013 07:51:54 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta12.westchester.pa.mail.comcast.net with comcast id f0eW1l0020vyq2s5C2ruhl; Wed, 22 May 2013 14:51:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id f2ru1l00F3ZTu2S3R2ruZd; Wed, 22 May 2013 14:51:54 +0000 Message-ID: <519CDB89.5020104@alum.mit.edu> Date: Wed, 22 May 2013 10:51:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <519C3316.7020707@nteczone.com> In-Reply-To: <519C3316.7020707@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369234314; bh=6d1cLEhGnaZIIOD8CiSGEAxoNDKBcBt6/+8QX7u/K08=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pTUyIT99gVx4gSvnmx8UqO28qP0DVzYmwepsHauXFYZ7vdpaBFyhKV/OxZ93OPWKl 8Vh0GJ0xZPGw1oVnYHtOl7kkbxbkdQzcQUq9312ONWdRfPedmbqF49SSEVKizA6IOu Bu/4MD25sxjM8j9r+eD92WR/kTTcjzBh/++vIB0xUM1kuoUkqyugpX8TGLdJY7FrAk CsLc92m4ew7b4pX7LKQo9jAT5emOyPBksm/Gqww0dvGsu1e1Cdtj/gE1eXwwWKzCgl RwWL/4LCcHyRtQsMoe2AzrZ7NyDwoTqNhG9Ib0LaHSsc81EzUDr2LWc/Lo15s0Xv16 tc92jTM57yELg== Subject: Re: [clue] Label attribute for CLUE 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, 22 May 2013 14:51:59 -0000 On 5/21/13 10:53 PM, Christian Groves wrote: > Hello > > We discussed in yesterday's virtual interim meeting about the use of the > a=label: in the signalling flows. > > My concern is with regards to the scope of the label attribute. Section > 4/RFC4574 says "The new attribute can be attached to 'm' lines in > multiple SDP documents allowing the application to logically group the > media streams across SDP sessions when necessary." > > Considering an MCU case my understanding is that any identities used in > CLUE only have scope to a particular advertisement. i.e. the MCU can use > the same Scene and capture ids in Advertisements to different endpoints. > > If label has the scope over multiple SDP sessions does this mean that > the CLUE strings used with label would have to be unique across all SDP > sessions in a MCU or gateway? I think you are reaching to far! I don't know why that statement is in the RFC. It appears to be an example of how it might be used. But I see nothing normative about that statement regarding the scope of the label value. My interpretation is that an application that participates in multiple SDP sessions could use the same label values in the SDP it generates for those sessions. The uniqueness of the values across multiple SDP documents, whether describing one or several sessions, is determined by the application. > Also RFC4796 section 3 on the Content Attribute indicates that a new > attribute was required because of a problem of backward compatibility. > Would this apply to a clue attribute also? For example if the endpoint > uses BFCP which uses label it would have to make sure labels for CLUE > didn't overlap. Also existing BFCP processing would just see a label > string. It wouldn't know that a=label:CLUE1 is not to be considered. As I read 4796, the backward compatibility issue would have arisen if some *dedicated* label values were identified for the purpose. The same would be true if clue tried to specify dedicated label values. That is why I was objecting to rob's proposal that the label prefix of "clue." be used to signal that the m-line is "clue controlled". Jonathan agreed with me on that. I think we agreed that if we need to signal that m-lines are clue controlled we will need something new in SDP. But that doesn't affect using labels as the means for referencing m-lines from the clue signaling. (Those labels will be assigned by the application.) Thanks, Paul > For CLUE I think we need to look at defining a specific SDP attribute > for this m-line -> encoding mapping. > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From rohanse2@cisco.com Wed May 22 08:24:19 2013 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 C6A3B21F9008 for ; Wed, 22 May 2013 08:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 fyO1XfwEveQG for ; Wed, 22 May 2013 08:24:14 -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 7282821F8FA5 for ; Wed, 22 May 2013 08:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2050; q=dns/txt; s=iport; t=1369236254; x=1370445854; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Gvpx2aCUWo6ICWVa9jqVWXqjBpBfsI4FjcNfzZdjOkg=; b=KvBDhn1Ft23Zy8fDfr3kG/89tDmg+37Np87Hxq63QC22mJ7fwpxRDl9o RUifK5eN+Ipa1kaQGAbvIsFkFyCdyPkTnr9WM3tmuZQO45P4JFA8zLK8P qqHHGNWj3PO/ASgQeIXK/+WV3Ufc+QjXzq37VgzAxJd5pgJVf4465tYD/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAPjhnFGQ/khN/2dsb2JhbABagwgxwW2BBRZ0giMBAQEDAThAEQshFg8JAwIBAgFFEwgBAYgDBrs3jyQWgz4DlziGHosigxA7 X-IronPort-AV: E=Sophos;i="4.87,722,1363132800"; d="scan'208";a="82762755" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 22 May 2013 15:24:12 +0000 Received: from [10.47.196.239] ([10.47.196.239]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4MFOAlO015885 for ; Wed, 22 May 2013 15:24:10 GMT Message-ID: <519CE37D.5080502@cisco.com> Date: Wed, 22 May 2013 16:25:49 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <519C3316.7020707@nteczone.com> <519CDB89.5020104@alum.mit.edu> In-Reply-To: <519CDB89.5020104@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Label attribute for CLUE 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, 22 May 2013 15:24:19 -0000 >> Also RFC4796 section 3 on the Content Attribute indicates that a new >> attribute was required because of a problem of backward compatibility. >> Would this apply to a clue attribute also? For example if the endpoint >> uses BFCP which uses label it would have to make sure labels for CLUE >> didn't overlap. Also existing BFCP processing would just see a label >> string. It wouldn't know that a=label:CLUE1 is not to be considered. > > As I read 4796, the backward compatibility issue would have arisen if > some *dedicated* label values were identified for the purpose. > > The same would be true if clue tried to specify dedicated label values. > That is why I was objecting to rob's proposal that the label prefix of > "clue." be used to signal that the m-line is "clue controlled". Jonathan > agreed with me on that. I think we agreed that if we need to signal that > m-lines are clue controlled we will need something new in SDP. But that > doesn't affect using labels as the means for referencing m-lines from > the clue signaling. (Those labels will be assigned by the application.) I agree that I was using the labels for two purposes - allowing the CLUE messages to refer to specific m-lines, and to indicate which m-lines were controllable in clue, and that while the former is suitable for label the latter is not. I don't think we'd require much new in SDP, though; rather than a new media attribute I think we just need to define a new group attribute, as I think this is something that falls well within RFC 5888. It allows us to define which streams are clue controlled, and the offer/answer rules match our needs nicely. For example, an SDP with 3 video m-lines, where the second and third are CLUE controlled might look like: ... a=group:CLUE 2 3 m=video 30000 RTP/AVP 96 ... a=mid:1 a=sendrecv m=video 30002 RTP/AVP 96 ... a=mid:2 a=sendonly m=video 30004 RTP/AVP 96 ... a=mid:3 a=sendonly Rob From pkyzivat@alum.mit.edu Wed May 22 08:53:20 2013 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 B336D21F966B for ; Wed, 22 May 2013 08:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.295 X-Spam-Level: X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.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 6JYV4PeIVaBL for ; Wed, 22 May 2013 08:53:07 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2921F965A for ; Wed, 22 May 2013 08:52:44 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta09.westchester.pa.mail.comcast.net with comcast id f2En1l0010SCNGk593sfTi; Wed, 22 May 2013 15:52:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id f3sf1l0113ZTu2S3V3sfhP; Wed, 22 May 2013 15:52:39 +0000 Message-ID: <519CE9C6.7020701@alum.mit.edu> Date: Wed, 22 May 2013 11:52:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <519C3316.7020707@nteczone.com> <519CDB89.5020104@alum.mit.edu> <519CE37D.5080502@cisco.com> In-Reply-To: <519CE37D.5080502@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369237959; bh=Tzr8174YqP54YrbX49LMQasn1JcJsAf4sbzR9RDE/MI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nBgL8nQrRq06ecg5AMnSjbKmmB/DNQ/XpsMsZm/rE31uyTSV//crdDKtQLkvUZSkl xONt9TLOFMiPmbjDXtzc/H05tqYs9vOpxAUTTEs3bCviamGV/kjoM3oVcEfGyDCb4K DjzqfX6ZUgzbczVk0QOl2pj1REOpxEMHyPt5q43Owpqx/m+1JIX9vsqW6/5GdPuRzB W9XXL9RZ+X6z8qKtOVXb1nTGw8iMvRBiUZt2TXxhbnXGoauXGeG+MsAsN/oJgqwFch 7VNfnhxOK+PAeLYYIDDBDIcXH7Y9+6JJgB5gtpMqcLaoRJmkzvKTBR/kuIVTdQlZM5 /uhRt0UoTDkkQ== Subject: Re: [clue] Label attribute for CLUE 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, 22 May 2013 15:53:25 -0000 On 5/22/13 11:25 AM, Robert Hansen wrote: > I agree that I was using the labels for two purposes - allowing the CLUE > messages to refer to specific m-lines, and to indicate which m-lines > were controllable in clue, and that while the former is suitable for > label the latter is not. I think we now have consensus on this. > I don't think we'd require much new in SDP, though; rather than a new > media attribute I think we just need to define a new group attribute, as > I think this is something that falls well within RFC 5888. It allows us > to define which streams are clue controlled, and the offer/answer rules > match our needs nicely. I agree that either could serve the purpose, and they are about equal in the amount of work required to define the SDP extension. (An attribute might be a little easier, but the difference is negligible.) The group might make the SDP a *little* smaller than attributes, assuming the mid values were already there for bundling. But again the difference is negligible. So I think this becomes a matter of taste. What you have below *looks* fairly nice. Thanks, Paul > For example, an SDP with 3 video m-lines, where the second and third are > CLUE controlled might look like: > > ... > a=group:CLUE 2 3 > m=video 30000 RTP/AVP 96 > ... > a=mid:1 > a=sendrecv > m=video 30002 RTP/AVP 96 > ... > a=mid:2 > a=sendonly > m=video 30004 RTP/AVP 96 > ... > a=mid:3 > a=sendonly > > Rob > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From ron.even.tlv@gmail.com Wed May 22 14:41:03 2013 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 A2C5911E8115 for ; Wed, 22 May 2013 14:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=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 7PD4yxqcJ-Zf for ; Wed, 22 May 2013 14:41:02 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 605B511E80A5 for ; Wed, 22 May 2013 14:41:02 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id d10so1437271eaj.3 for ; Wed, 22 May 2013 14:41:01 -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=H6yBgdfPQcPOWVtnyVjusN1ZX62h2HK1ybHUbpiDvPk=; b=YReomBncZ9lsRW0n9cYie0BJ1hls3ryLTacwPqTIvhQUFhQKTnzwLHsBZ1ezqchdd5 LLqRFFYja3c8togWffaiaP71o2wzhA6eLotQVD+U1hy4N7/U2NE1Paou1fn7lVQ+dPIr 39qpEVsnBwZKqbbehipdMsW9xeJx4g8Rzzs5S+zHAhg10svR7u4iyjO/yA5Z26b3msFK MNdY6HRh2n+tTbNKhyU1U1csjBfkoA+8+7yCPVwEacM2Is3WITXkLiipvKg6pHM+ktY0 OIr89nAlyzNy0ZCn8RKUaU+ibwEnKWMwrvOyIksY14c055eEJuGbOKFY0BQM5bEqPr1D u9Ag== X-Received: by 10.14.95.4 with SMTP id o4mr19450544eef.2.1369258861485; Wed, 22 May 2013 14:41:01 -0700 (PDT) Received: from RoniE (bzq-79-182-167-109.red.bezeqint.net. [79.182.167.109]) by mx.google.com with ESMTPSA id m48sm12771213eeh.16.2013.05.22.14.40.59 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 May 2013 14:41:00 -0700 (PDT) From: "Roni Even" To: "'Robert Hansen'" , References: <519C3316.7020707@nteczone.com> <519CDB89.5020104@alum.mit.edu> <519CE37D.5080502@cisco.com> In-Reply-To: <519CE37D.5080502@cisco.com> Date: Thu, 23 May 2013 00:39:59 +0300 Message-ID: <020b01ce5734$ea6beae0$bf43c0a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXVzND6KwL9covj72s7VhBc2+UXQI+/IhDAYLp9UqYYatQsA== Content-Language: en-us Subject: Re: [clue] Label attribute for CLUE 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, 22 May 2013 21:41:03 -0000 Hi, I agree that using group works fine based on the current decision to start with no RTP multiplexing. I think that if we will support more than one RTP stream per m-line (Plan B) it will work only if all multiplexed RTP streams in the m-line are CLUE controlled. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Robert Hansen > Sent: 22 May, 2013 6:26 PM > To: clue@ietf.org > Subject: Re: [clue] Label attribute for CLUE > > > >> Also RFC4796 section 3 on the Content Attribute indicates that a new > >> attribute was required because of a problem of backward compatibility. > >> Would this apply to a clue attribute also? For example if the > >> endpoint uses BFCP which uses label it would have to make sure labels > >> for CLUE didn't overlap. Also existing BFCP processing would just see > >> a label string. It wouldn't know that a=label:CLUE1 is not to be considered. > > > > As I read 4796, the backward compatibility issue would have arisen if > > some *dedicated* label values were identified for the purpose. > > > > The same would be true if clue tried to specify dedicated label values. > > That is why I was objecting to rob's proposal that the label prefix of > > "clue." be used to signal that the m-line is "clue controlled". > > Jonathan agreed with me on that. I think we agreed that if we need to > > signal that m-lines are clue controlled we will need something new in > > SDP. But that doesn't affect using labels as the means for referencing > > m-lines from the clue signaling. (Those labels will be assigned by the > > application.) > > I agree that I was using the labels for two purposes - allowing the CLUE > messages to refer to specific m-lines, and to indicate which m-lines were > controllable in clue, and that while the former is suitable for label the latter is > not. > > I don't think we'd require much new in SDP, though; rather than a new media > attribute I think we just need to define a new group attribute, as I think this > is something that falls well within RFC 5888. It allows us to define which > streams are clue controlled, and the offer/answer rules match our needs > nicely. > > For example, an SDP with 3 video m-lines, where the second and third are > CLUE controlled might look like: > > ... > a=group:CLUE 2 3 > m=video 30000 RTP/AVP 96 > ... > a=mid:1 > a=sendrecv > m=video 30002 RTP/AVP 96 > ... > a=mid:2 > a=sendonly > m=video 30004 RTP/AVP 96 > ... > a=mid:3 > a=sendonly > > Rob > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed May 22 15:13:17 2013 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 DD80D11E812F for ; Wed, 22 May 2013 15:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.307 X-Spam-Level: X-Spam-Status: No, score=0.307 tagged_above=-999 required=5 tests=[AWL=-0.456, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RDNS_NONE=0.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 n2BvpOi0aeRk for ; Wed, 22 May 2013 15:13:13 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6FB11E813A for ; Wed, 22 May 2013 15:13:12 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id fA5P1l00116LCl05CADBe9; Wed, 22 May 2013 22:13:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id fADB1l00u3ZTu2S3SADB07; Wed, 22 May 2013 22:13:11 +0000 Message-ID: <519D42F6.8030406@alum.mit.edu> Date: Wed, 22 May 2013 18:13:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <519C3316.7020707@nteczone.com> <519CDB89.5020104@alum.mit.edu> <519CE37D.5080502@cisco.com> <020b01ce5734$ea6beae0$bf43c0a0$@gmail.com> In-Reply-To: <020b01ce5734$ea6beae0$bf43c0a0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1369260791; bh=jxHa+Yuh2w7rVESFFMCwP3GxUv2XuBqr0hSNL5qzp8A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lwCc44/JHO16iI+KvsasnmWsTYaEQ8en1snMfzg5zcGelg3Jra2Hfd6ILmOJTdFkX UVCdB7CWrfkS+jfJeOju0vJQlAMy+P2nnYQPhYEV2JZX2dum6OcQGHCEcx4bOB4o73 TEbatKcE3n3zPVOl63WL3TzzOX0xYBuy2OGCqrHrBCvmyqmS4gGxbXOCTcJZSPtCOo lvDtCLmFsmQjl0C9Uj44OdQMWcpuruk3Yai50jY5xpZqMm0Kq3p073VDs4S/8Hd2dw VHKFiomLNrdqn9gPnhfKYPoERvR+WM+JJDTqM3ZnvwoSgUKNcxX6dOOYC+CHbbRzU4 Hns5DxLfRHJJg== Subject: Re: [clue] Label attribute for CLUE 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, 22 May 2013 22:13:18 -0000 On 5/22/13 5:39 PM, Roni Even wrote: > Hi, > I agree that using group works fine based on the current decision to start > with no RTP multiplexing. > I think that if we will support more than one RTP stream per m-line (Plan > B) it will work only if all multiplexed RTP streams in the m-line are CLUE > controlled. I agree with your last point. But I think it would be very unwise to have an m-line that was "partially controlled" by clue. So I don't see that as an issue. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Robert Hansen >> Sent: 22 May, 2013 6:26 PM >> To: clue@ietf.org >> Subject: Re: [clue] Label attribute for CLUE >> >> >>>> Also RFC4796 section 3 on the Content Attribute indicates that a new >>>> attribute was required because of a problem of backward compatibility. >>>> Would this apply to a clue attribute also? For example if the >>>> endpoint uses BFCP which uses label it would have to make sure labels >>>> for CLUE didn't overlap. Also existing BFCP processing would just see >>>> a label string. It wouldn't know that a=label:CLUE1 is not to be > considered. >>> >>> As I read 4796, the backward compatibility issue would have arisen if >>> some *dedicated* label values were identified for the purpose. >>> >>> The same would be true if clue tried to specify dedicated label values. >>> That is why I was objecting to rob's proposal that the label prefix of >>> "clue." be used to signal that the m-line is "clue controlled". >>> Jonathan agreed with me on that. I think we agreed that if we need to >>> signal that m-lines are clue controlled we will need something new in >>> SDP. But that doesn't affect using labels as the means for referencing >>> m-lines from the clue signaling. (Those labels will be assigned by the >>> application.) >> >> I agree that I was using the labels for two purposes - allowing the CLUE >> messages to refer to specific m-lines, and to indicate which m-lines were >> controllable in clue, and that while the former is suitable for label the > latter is >> not. >> >> I don't think we'd require much new in SDP, though; rather than a new > media >> attribute I think we just need to define a new group attribute, as I think > this >> is something that falls well within RFC 5888. It allows us to define which >> streams are clue controlled, and the offer/answer rules match our needs >> nicely. >> >> For example, an SDP with 3 video m-lines, where the second and third are >> CLUE controlled might look like: >> >> ... >> a=group:CLUE 2 3 >> m=video 30000 RTP/AVP 96 >> ... >> a=mid:1 >> a=sendrecv >> m=video 30002 RTP/AVP 96 >> ... >> a=mid:2 >> a=sendonly >> m=video 30004 RTP/AVP 96 >> ... >> a=mid:3 >> a=sendonly >> >> Rob >> _______________________________________________ >> 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 May 24 14:47:42 2013 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 776E111E80E2 for ; Fri, 24 May 2013 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 OHulfcYGWCnY for ; Fri, 24 May 2013 14:47:38 -0700 (PDT) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id C7E7211E8126 for ; Fri, 24 May 2013 14:47:36 -0700 (PDT) Received: by mail-qe0-f49.google.com with SMTP id a11so2833340qen.8 for ; Fri, 24 May 2013 14:47:36 -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=Pv4wPOSYqsVua+b8IyG0wVB5VVLqCzG6n/2ZkglDtwA=; b=M6wJvfHfGuWCPgLJ0USgb/0qnyqbDJczZ7Ap72dEEXF/eniheP86NR2uMwHjLiBbXX xa7C+Ijbxtc38jxPJbFRDaBWCksd8n0hgukaWLPSz3O73yAezX6z9+vGgNnqop0ZjGuN TgHM04MW577CL209bTOkoimUi/fsYuWeVhYxur8sklFU9gH6PduRbyMDHeBiJupQ8b1J abAhMX9vHeiikuQLp1XatMjSbWjLcshHZ8eiwE0NdWKD3P1PawD0WVZ6GfrEd8fnFQWL Kp7pEKt0C8Bsmi9OJgtgsYyN7GKESwz3KKx0/2AV7yoPS19c2h8cDoJnH1jyv1g4FY2i 8Yug== MIME-Version: 1.0 X-Received: by 10.229.177.10 with SMTP id bg10mr6643265qcb.135.1369432056082; Fri, 24 May 2013 14:47:36 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Fri, 24 May 2013 14:47:36 -0700 (PDT) Date: Fri, 24 May 2013 16:47:36 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Minutes: CLUE WG Interim meeting 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, 24 May 2013 21:47:42 -0000 FYI, the minutes (and all the presentations) for the CLUE WG interim meeting held on Tuesday, May 21st, 2013 are now available in the proceedings. http://www.ietf.org/proceedings/interim/2013/05/21/clue/proceedings.html Note, that the link to the recording is in the minutes. Please let us know if there are any questions, comments or points for clarification. Regards, Mary. From mary.ietf.barnes@gmail.com Wed May 29 08:30:04 2013 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 EEC0F21F9501 for ; Wed, 29 May 2013 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_BAYES_5x7=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 H4J30OB5hjyd for ; Wed, 29 May 2013 08:29:59 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id A800B21F94DC for ; Wed, 29 May 2013 08:29:54 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id 1so5222085qec.11 for ; Wed, 29 May 2013 08:29:54 -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=b7OvlWPljWCwmLJmOpntbY+58Gyp8CkWmYc84oPlYSg=; b=m/9aJiNKd3RnYQsfrFgq8I0lVV/WpvBenN/A09euvvNivnh8awR/HhVpl66PettgGm mbyLqAT8VJmms6A9w1vPZ1R8/mZVwAg1p3W2X1yHzVwXwHziOVENHE4sKbAlVFtDZR3L CH+kwbHJNDqEOwEvxbAWU8ZT+0Hkdz0yeer91pUGNgsh8d9PV9bVecmj2SQiiCaJMg6h pvJgtaScXLDM6rMsp/X1Y3C/sjkg6Voy+MgbxXEnxtTeN5nR44YHSzhL1Zv4XYCIdz3i plpCPP4mdK8kkphKN5vSp8RcvaKQl3U09nyzouifJkHv3N9PIQao0fTAB7GQZ0bYCA63 kw8g== MIME-Version: 1.0 X-Received: by 10.49.87.135 with SMTP id ay7mr3452002qeb.38.1369841394163; Wed, 29 May 2013 08:29:54 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Wed, 29 May 2013 08:29:54 -0700 (PDT) Date: Wed, 29 May 2013 10:29:54 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Doodle: Poll for CLUE WG Virtual Interim 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, 29 May 2013 15:30:05 -0000 Hi all, As discussed at the meeting last week, I would like to arrange another virtual interim meeting prior to IETF-87. The objective would be to close off any remaining issues with the framework (per the actions from the virtual interim) and focus on the signaling solution. If folks could please fill out the doodle no later than Monday, June 3 @ 5pm Pacific, so we can get it arranged. If the week of June 17th dates work out, we would need to announce the meeting by the week of June 3rd to allow the 2 weeks notice. http://www.doodle.com/kpwy33fvqzcyip8n Regards, Mary. From roni.even@mail01.huawei.com Wed May 29 11:53:36 2013 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 99BB621F95EA for ; Wed, 29 May 2013 11:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, SARE_BAYES_5x7=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 eeqkO4ICZ9ng for ; Wed, 29 May 2013 11:53:25 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (unknown [58.251.153.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5B121F9579 for ; Wed, 29 May 2013 11:53:08 -0700 (PDT) Received: from 172.24.2.15 (EHLO szxpml204-edg.exmail.huawei.com) ([172.24.2.15]) by szxrg12-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id BPY19582; Thu, 30 May 2013 02:52:35 +0800 (CST) Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 30 May 2013 02:52:32 +0800 Received: from SZXPML504-MBX.exmail.huawei.com ([169.254.3.10]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.01.0323.003; Thu, 30 May 2013 02:52:34 +0800 From: Roni Even To: Mary Barnes , CLUE Thread-Topic: [clue] Doodle: Poll for CLUE WG Virtual Interim Thread-Index: AQHOXIF63JgfL74nbkSZ40pJB0UkQJkcgg9V Date: Wed, 29 May 2013 18:52:33 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C218001C4F@szxpml504-mbx.exmail.huawei.com> References: 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.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Doodle: Poll for CLUE WG Virtual Interim 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, 29 May 2013 18:53:36 -0000 Mary, I did not see for how many hours you propose to meet Roni ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Wednesday, May 29, 2013 6:29 PM To: CLUE Subject: [clue] Doodle: Poll for CLUE WG Virtual Interim Hi all, As discussed at the meeting last week, I would like to arrange another virtual interim meeting prior to IETF-87. The objective would be to close off any remaining issues with the framework (per the actions from the virtual interim) and focus on the signaling solution. If folks could please fill out the doodle no later than Monday, June 3 @ 5pm Pacific, so we can get it arranged. If the week of June 17th dates work out, we would need to announce the meeting by the week of June 3rd to allow the 2 weeks notice. http://www.doodle.com/kpwy33fvqzcyip8n Regards, Mary. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From mary.ietf.barnes@gmail.com Wed May 29 12:13:23 2013 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 C3EDA21F96C6 for ; Wed, 29 May 2013 12:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 wQbvCbbQ8eV6 for ; Wed, 29 May 2013 12:13:22 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2568121F96BA for ; Wed, 29 May 2013 12:13:22 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id hu16so2404783qab.20 for ; Wed, 29 May 2013 12:13: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 :content-type; bh=gj0lzgZuNVuaES0Zot9G5LbmfEBraol2Th3luNqskG0=; b=bh54upzPhKpJmr3LgZoR9iNz9qg7A7hPWG6cegkLsSSIdDBtnrin/tbO2dkir1z/iP gxFtwauegxO85c4JZkccSamfok1GVYx2v/bZT+GWoWg0hDdnR/rep3GSYCSAkILKDX6S 53DCDEr6wIjbn2r3rCK4M/nD6UPm2L0irl7Ft4Vw4L8vWxbMw01HcU/rSNTl6CXnDx1c qSihZh16LwhfImer5gRXNiAsDmdMietMs1B2nJ3NY0eDG0MXn3LuFx3LHpzSdPek4mEw 33VVSI2gMlAYFc0ESvHakhjQrM/bI/KAPS8p9HMlqUm9I4mo1zS82kRA0y2KPSWhJZGJ MNFw== MIME-Version: 1.0 X-Received: by 10.229.21.201 with SMTP id k9mr45413qcb.91.1369854801607; Wed, 29 May 2013 12:13:21 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Wed, 29 May 2013 12:13:21 -0700 (PDT) In-Reply-To: <51A65017.4090502@jitsi.org> References: <51A65017.4090502@jitsi.org> Date: Wed, 29 May 2013 14:13:21 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: [rtcweb] No Plan 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, 29 May 2013 19:13:24 -0000 As chair, I strongly encourage folks to review this proposal and comment on the RTCWEB mailing list (while I personally think the discussion should be on the MMUSIC mailing list, it seems impossible to get RTCWEB folks to do that consistently). Individually, I really like this approach of minimizing dependency and interactions with SDP O/A and leaving the more complex signaling to the applications (e.g., CLUE). Mary. ---------- Forwarded message ---------- From: Emil Ivov Date: Wed, May 29, 2013 at 1:59 PM Subject: [rtcweb] No Plan To: rtcweb@ietf.org Hey all, Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less. The following "no plan" draft attempts to present one such approach: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP. Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways. Comments are welcome! Cheers, Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From mary.ietf.barnes@gmail.com Wed May 29 12:13:56 2013 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 7DE6721F9790 for ; Wed, 29 May 2013 12:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 BmouTlRKb+vy for ; Wed, 29 May 2013 12:13:54 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 4140821F96BA for ; Wed, 29 May 2013 12:13:51 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id bs12so2438301qab.1 for ; Wed, 29 May 2013 12:13:50 -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=l2ej+uEJ1ouB9dc92qxYmoQWlPpXGiUQMk5hUxZjURI=; b=h9JjXsxR1Yp51SXV68xuOipX4UXxlCo8L4jLxn9daFJjKGPUCqRDLnrBbZeJVv6+QP HrnpLC5Um0NRb8ubFJlnJq8w36nzvPlcachyEN86dXyOpEZajWW9wcP7o9u49GmpRvBT 8Sig4mDGI/HfTPdJqxl2mU5CemMBELD1kdgrMXDkYnTMM5Pp8IYkgL8OxyI0mBCkEya3 SMexJ9ZsxDvjWhnVaqCDNjddAwPht8yLGJwiu8ZUwuVmb0JbMulijqTFrf4YXzOIhP1C UHtL3Kvy75m6BiifkrkhFOrrLAUtauf7UV3e6krRXcLaSj2KTWowaom5urPjqtKRH8N/ JoOQ== MIME-Version: 1.0 X-Received: by 10.224.35.67 with SMTP id o3mr4533211qad.11.1369854830622; Wed, 29 May 2013 12:13:50 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Wed, 29 May 2013 12:13:50 -0700 (PDT) In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C218001C4F@szxpml504-mbx.exmail.huawei.com> References: <760B7D45D1EFF74988DBF5C2122830C218001C4F@szxpml504-mbx.exmail.huawei.com> Date: Wed, 29 May 2013 14:13:50 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] Doodle: Poll for CLUE WG Virtual Interim 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, 29 May 2013 19:13:57 -0000 Sorry, the intent would be a two hour meeting. Mary. On Wed, May 29, 2013 at 1:52 PM, Roni Even wrote: > Mary, > I did not see for how many hours you propose to meet > Roni > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com] > Sent: Wednesday, May 29, 2013 6:29 PM > To: CLUE > Subject: [clue] Doodle: Poll for CLUE WG Virtual Interim > > Hi all, > > As discussed at the meeting last week, I would like to arrange another > virtual interim meeting prior to IETF-87. The objective would be to > close off any remaining issues with the framework (per the actions > from the virtual interim) and focus on the signaling solution. If > folks could please fill out the doodle no later than Monday, June 3 @ > 5pm Pacific, so we can get it arranged. If the week of June 17th > dates work out, we would need to announce the meeting by the week of > June 3rd to allow the 2 weeks notice. > > http://www.doodle.com/kpwy33fvqzcyip8n > > Regards, > Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed May 29 14:11:07 2013 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 E91EB21F856D; Wed, 29 May 2013 14:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 IHnKibaij5t0; Wed, 29 May 2013 14:11:05 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F030221F9677; Wed, 29 May 2013 14:10:47 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id z1so5018279qcx.17 for ; Wed, 29 May 2013 14:10:47 -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; bh=IoMb7hZ7/BPxALOnAjjDJXimCUugMvCMrzLIz77MQ2I=; b=epXzv4hJuvh4JK8LctVwKmBb63P0IaU6hpZEaMqlL3j2z5Dy65wB4/GnfS8xBTPpX4 tNopkmVTx5BTRPSoDPbyymeeBbpQCNPHX68rkNYNbts1aKoXVpopL5eMrBwCXUV42IH3 ei5SnXLjtxVPTkx6zRonQxxVbpqdJGTFHuTgSVFsgJENlnipgZ8QTvvz79f2YB4JvBr1 DTwsfIQNeQiYEFTiw7OWuHUSZ4vGg2NritQkUiaygTge7T/o391/WeK7zx/oP/rvCsMh da4RtwvQcYuPMj8hvRJ8YIMkojBveH1eZ5lLy+vR7NdVENNJ2kHuI4gxYZP3L+eq6LVg CEqA== MIME-Version: 1.0 X-Received: by 10.229.177.10 with SMTP id bg10mr1602426qcb.135.1369861847369; Wed, 29 May 2013 14:10:47 -0700 (PDT) Received: by 10.49.41.68 with HTTP; Wed, 29 May 2013 14:10:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 May 2013 16:10:47 -0500 Message-ID: From: Mary Barnes To: DISPATCH , "rai@ietf.org" , CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: Nomcom 2013-14 Volunteering - 2nd Call 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, 29 May 2013 21:11:07 -0000 Sorry for the multiple copies, but just in case you are not subscribed to the IETF announce or IETF discussion lists. This is a very important volunteer opportunity, as the voting members selected from this pool of volunteers will be responsible for selecting the individuals to serve in IETF leadership positions. Please consider volunteering - note that volunteering doesn't necessarily commit you as the process for selection is entirely random. However, the more diverse set of volunteers, the more diverse nomcom we will have. Mary. ---------- Forwarded message ---------- From: Mankin, Allison Date: Wed, May 29, 2013 at 4:04 PM Subject: Nomcom 2013-14 Volunteering - 2nd Call To: "ietf-announce@ietf.org" Cc: "" Hi, everyone, Remember that I'm challenging the IETF to come up with 200 volunteers for the upcoming nomcom. You can volunteer just by hitting Reply to this email. What are you waiting for?? The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF population. Respond to the 200-volunteer challenge and hit Reply right now. (Well, much as I want you to do this, please look below at the posts being filled and be sure you are willing to forgo trying for any of them this year). The official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 11:59 pm EDT (UTC -4 hours) June 16, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). You should expect an email response from me within 3 business days stating whether or not you are qualified (and added to the list). If you don't receive this response, please re-send your email adding the tag "RESEND" to the subject line. Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. Please help us meet the 200-volunteer challenge by hitting Reply to this message today. Allison Allison Mankin Nomcom Chair 2013-2014 From fandreas@cisco.com Wed May 29 14:21:33 2013 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 83A8021F9684 for ; Wed, 29 May 2013 14:21:29 -0700 (PDT) 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=[AWL=-0.000, 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 yJaZq+du-ebp for ; Wed, 29 May 2013 14:21:24 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFA121F9421 for ; Wed, 29 May 2013 14:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5611; q=dns/txt; s=iport; t=1369862484; x=1371072084; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=zCPoZRK+gFqzpZ7ynIE8/7TACS4qXu/OwZ+A6CqupV4=; b=SxC0wK3VRgNpntD2cNYb4xHNGVIQnJxsfbVN1Fn1WaxC6A6zBBAxNSqL 3H67BLrjO7zgo7l4An/I3xhPLGUSSKJO63amRkOuvsD+8KYXCIIuTuwh5 Efao0qY03ZuCDHiLC9omFP6IkhlGGACoRYJffxi2A20GVVCUmylCDgdTy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUHAG1vplGtJXHB/2dsb2JhbABagwkwiRm4a4EKFnSCIwEBAQQBAQFrCg0EHAMBAgoWDwkDAgECARUmAggTBgIBAQWIBAy5e48CGAaDUQOXO5FAgysg X-IronPort-AV: E=Sophos;i="4.87,766,1363132800"; d="scan'208,217";a="216532033" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 29 May 2013 21:21:22 +0000 Received: from rtp-fandreas-8714.cisco.com (rtp-fandreas-8714.cisco.com [10.117.7.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4TLLMeu029451 for ; Wed, 29 May 2013 21:21:22 GMT Message-ID: <51A67152.5070608@cisco.com> Date: Wed, 29 May 2013 17:21:22 -0400 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: clue@ietf.org References: <51A6700B.40108@cisco.com> In-Reply-To: <51A6700B.40108@cisco.com> X-Forwarded-Message-Id: <51A6700B.40108@cisco.com> Content-Type: multipart/alternative; boundary="------------010205040207000400030204" X-Mailman-Approved-At: Wed, 29 May 2013 14:56:33 -0700 Subject: [clue] Fwd: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 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, 29 May 2013 21:21:33 -0000 This is a multi-part message in MIME format. --------------010205040207000400030204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013 Date: Wed, 29 May 2013 17:15:55 -0400 From: Flemming Andreasen To: IETF Announcement List CC: mmusic Greetings This is to announce a(nother) virtual interim meeting for the MMUSIC Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and signaling at the SSRC level). A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts: http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt You may also want to look at http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt Thanks -- Ari & Flemming (MMUSIC co-chairs) PS: Per our previous interim meeting announcement, we tried to schedule a longer and in-person physical interim meeting, however it has proven impossible to find a set of dates where we could get critical mass for such a meeting. Scheduling even a virtual interim before the Berlin IETF has been surprisingly difficult with the above date being the only viable option at this point. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --------------010205040207000400030204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI


-------- Original Message --------
Subject: [MMUSIC] MMUSIC Working Group Virtual Interim Meeting, June 17, 2013
Date: Wed, 29 May 2013 17:15:55 -0400
From: Flemming Andreasen <fandreas@cisco.com>
To: IETF Announcement List <ietf-announce@ietf.org>
CC: mmusic <mmusic@ietf.org> 


Greetings

This is to announce a(nother) virtual interim meeting for the MMUSIC Working Group to take place on Monday, June 17, from 7:00 am - 10:00 am
Pacific Time. The goal of this meeting is to come to a resolution on the so-called "Plan A" or "Plan B" approach related to SDP signaling needed
by RTCWeb, CLUE, etc. (i.e. do we have potentially lots of "m=" lines or very few "m=" lines and to what extent is there sub-negotation and
signaling at the SSRC level).

A more detailed agenda and logistics will be sent out separately. For now, people should take a close look at the following two drafts:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt

You may also want to look at
http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt


Thanks

-- Ari & Flemming (MMUSIC co-chairs)


PS: Per our previous interim meeting announcement, we tried to schedule a longer and in-person physical interim meeting, however it has proven impossible to find a set of dates where we could get critical mass for such a meeting. Scheduling even a virtual interim before the Berlin IETF has been surprisingly difficult with the above date being the only viable option at this point.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic


--------------010205040207000400030204-- From prvs=7862594b53=christer.holmberg@ericsson.com Thu May 30 00:22:43 2013 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 D244E21F942B for ; Thu, 30 May 2013 00:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.945 X-Spam-Level: X-Spam-Status: No, score=-5.945 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 UIYFR7HN82jo for ; Thu, 30 May 2013 00:22:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A2BD121F882A for ; Thu, 30 May 2013 00:22:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7f5d6d000003d54-8c-51a6fe3c8c71 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 54.C5.15700.C3EF6A15; Thu, 30 May 2013 09:22:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.167]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0328.009; Thu, 30 May 2013 09:22:36 +0200 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Fwd: [rtcweb] No Plan Thread-Index: AQHOXJ6w4pPZWNQxOUWhx5DufiT5nZkcZmaAgADrufA= Date: Thu, 30 May 2013 07:22:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C37D10F@ESESSMB209.ericsson.se> References: <51A65017.4090502@jitsi.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvra7Nv2WBBt9btCz2n7rMbPF5/35m ByaPnbPusnssWfKTKYApitsmKbGkLDgzPU/fLoE74+GXXUwFewQr7h2+wdrAuISvi5GTQ0LA ROL4qfdMELaYxIV769m6GLk4hAQOM0pMa+5khnCWMEqc/dPD2MXIwcEmYCHR/U8bpEFEwEni wsv3LCC2sICmxOIHy5gh4loSiy9+Y4KwrSRmHr4FFmcRUJXomLkXzOYV8JX43b6GFcQWEsiX eNr2AMzmFAiUuL8Xop4R6KDvp9aAzWEWEJe49WQ+1KECEkv2nGeGsEUlXj7+xwpymoSAosTy fjmIch2JBbs/sUHY2hLLFr6GWisocXLmE5YJjKKzkEydhaRlFpKWWUhaFjCyrGJkz03MzEkv N9zECIyFg1t+6+5gPHVO5BCjNAeLkjivHu/iQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJL qoGx8+GnvvtxR0TLZTicZZ5p/8zc17hdqCLJJ/LOnCfzT67NuCfO6vf6TuzNry+5w6erzeP9 ONnv/honj2uRWe/ZTQ7LGlT5nFkU9F/sUoKr/YIfAhWKy3ddfM5uddWwT/vsz+KHnFx/36pc vibDWWfw4sbRj4a9imZLbXPXJpsWF+9ny90fn5CjxFKckWioxVxUnAgAJH8JhFgCAAA= Subject: Re: [clue] Fwd: [rtcweb] No Plan 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, 30 May 2013 07:22:43 -0000 Hi Mary, > As chair, I strongly encourage folks to review this proposal and comment = on the RTCWEB mailing list (while I personally think the discussion should= =20 > be on the MMUSIC mailing list, it seems impossible to get RTCWEB folks to= do that consistently). I've managed to move the BUNDLE discussions to the MMUSIC list ;) > Individually, I really like this approach of minimizing dependency and in= teractions with SDP O/A and leaving the more complex signaling to the appli= cations (e.g., CLUE). I have nothing against trying to minimize SDP O/A transactions. But, from a= CLUE perspective please note the following statement in the draft: "For the sake of interoperability this specification strongly advises against the use of multiple m=3D lines for a single media type." That goes against the CLUE signaling proposals we've been discussing. Regards, Christer ---------- Forwarded message ---------- From: Emil Ivov Date: Wed, May 29, 2013 at 1:59 PM Subject: [rtcweb] No Plan To: rtcweb@ietf.org Hey all, Based on many of the discussions that we've had here, as well as many other= s that we've had offlist, it seemed like a good idea to investigate a negot= iation alternative that relies on SDP and Offer/Answer just a little bit le= ss. The following "no plan" draft attempts to present one such approach: http://tools.ietf.org/html/draft-ivov-rtcweb-noplan The draft relies on conventional use of SDP O/A but leaves the intricacies = of multi-source scenarios to application-specific signalling, with potentia= lly a little help from RTP. Hopefully, proponents of Plans A and B would find that the interoperability= requirements that concerned them can still be met with "no plan". Of cours= e they would have to be addressed by application-specific signalling and/or= signalling gateways. Comments are welcome! Cheers, Emil -- https://jitsi.org _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue