From christer.holmberg@ericsson.com Fri Mar 1 02:22:09 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 B177D21F86D5 for ; Fri, 1 Mar 2013 02:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdlxF2t+1I-E for ; Fri, 1 Mar 2013 02:22:07 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3044221F87E0 for ; Fri, 1 Mar 2013 02:22:07 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-01-5130814e9f06 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DA.84.19728.E4180315; Fri, 1 Mar 2013 11:22:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Fri, 1 Mar 2013 11:22:05 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Christer's initial comments on framework-09 Thread-Index: Ac4VroADjRD7KAXuTk65+jHWtYvPhAAUOg6AABjxL+A= Date: Fri, 1 Mar 2013 10:22:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10DEE8@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> <512FE233.8010104@nteczone.com> In-Reply-To: <512FE233.8010104@nteczone.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja5fo0GgQeMdcYsv7xtZLPafuszs wOSxZMlPJo8V52eyBDBFcdmkpOZklqUW6dslcGVcX3KTreCuQMXlLwvZGxiX83YxcnBICJhI TH4i28XICWSKSVy4t56ti5GLQ0jgEKNEx9NFUM4iRolLFyaxgDSwCVhIdP/TBmkQEQiX6Nh2 hRHEFhawl3gxYQ4TRNxBYt6sVYwQtpXE3J4GsDiLgIpET889ZhCbV8Bb4smiaewgtpBArsS/ VX/YQGxOAR2Jef3HwXoZgQ76fmoNWC+zgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtR4ur0 5VD1OhILdn9ig7C1JZYtfA21V1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxciem5iZk15u tIkRGAkHt/xW3cF455zIIUZpDhYlcd5w1wsBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhj5 nm6+8bH++JOlzUdVppas2l9waVHM9Z/sr3/Z32yscfOd9YyrZv4Wz+4fZ44na+seTvqfFigT v3VJX/zeZUk5U0R/3n9cKpS9JSqiasKnVfUc6pybJ6/dtC/H5HVXN8PLvmlccUVHGUJOVTwP mGirq6so+PX9Kb2n25pslvfdZYlcs/DlIY8WJZbijERDLeai4kQAFVEZm1ICAAA= Subject: Re: [clue] Christer's initial comments on framework-09 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, 01 Mar 2013 10:22:09 -0000 Hi, > For Q1 I think the definition of CSE indicates that its an entire scene. Yes, the definition is probably ok. I am referring to text elsewhere in the= draft. > With respect to Q2, I agree that's why we made the sending of the simulta= neous set optional. If the provider doesn't send the STS the consumer assum= es that all captures in the CSE can be provided simultaneously. EVEN if the provider sends STS, I think a provider MUST be able to provide = a CSE. In my opinion, the only use of STS is when one wants to simultaneously prov= ide captures belonging to different CSE/CS. But, as I indicated earlier, in= my opinion is would be better to indicate Simultaneous CSE Set. Regards, Christer On 28/02/2013 11:24 PM, Christer Holmberg wrote: > > Hi, > > A couple of initial comments: > > ------------------- > > Q1: Capture Scene and Capture Scene Entry editorial > > In a few places, there is text saying that "a Capture Scene includes=20 > one or more Capture Scene Entries". I think that is a little=20 > misleading, because it sounds like one uses one or more CSEs in order=20 > to describe a CS. > > But, as each single CSE describes the whole scene, I think the text=20 > should talk about CSEs providing alternatives for providing the CS. > > ------------------- > > Q2: Simultaneous Transmission Set > > We had a long discussion about this some time ago, and we never came=20 > to a conclusion. I know there is another thread about STSs also, and I=20 > will reply to that. > > But, I think that an endpoint shall always be able to simultaneously=20 > provide all captures within a given CSE. So, there is no need to=20 > explicitly advertise that the captures associated with a given CSE can=20 > be provided simultaneously. > > ------------------- > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Mar 1 03:17: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 1396421F89B2 for ; Fri, 1 Mar 2013 03:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1oKGp5HowTx for ; Fri, 1 Mar 2013 03:17:58 -0800 (PST) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6952821F8824 for ; Fri, 1 Mar 2013 03:17:57 -0800 (PST) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 6BH41l0021Y3wxoA3BHwQP; Fri, 01 Mar 2013 11:17:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([113.108.97.1]) by omta15.emeryville.ca.mail.comcast.net with comcast id 6BFa1l00901nDsp8bBFg8i; Fri, 01 Mar 2013 11:15:50 +0000 Message-ID: <51308DD6.4030309@alum.mit.edu> Date: Fri, 01 Mar 2013 19:15:34 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> <512FE233.8010104@nteczone.com> <7594FB04B1934943A5C02806D1A2204B10DEE8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10DEE8@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=1362136676; bh=79YHU3xLGNTQMCGE228twFmpp8vQgmmlhTs6w5jeSj0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NftW0KsuJhEBWlhQmCTFdgknteMRHMXMRLhVe4jLqjxFI2eA4eLJwdNSB8o2EvxHL gHPbcBfQNT6ol8/MRO2Gws8U/nDexItysbyqxOXk8Dy4cY8k9Gd6vClAQR2V9gP6qy OdS+cEf91fkaNJvJm7+IPrOIqNiBPKBS9ytFrp36RWLbDHxNgd9U966mAVtZCmKbr3 1rP+voiAh8qmEjBIlWokfC4vlghvxL2H6/fFPACaQw9XABDM0KIx60WuyJ2TAjHnvC Qbbld6nKcUOgIt2Q1t6SPZQtTjTORY9oYbH0JqDSu4amQh5Oh6+Tvz6lF9F21XFdtf FENRIBeCSoSQA== Subject: Re: [clue] Christer's initial comments on framework-09 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, 01 Mar 2013 11:17:59 -0000 On 3/1/13 6:22 PM, Christer Holmberg wrote: > Hi, > >> For Q1 I think the definition of CSE indicates that its an entire scene. > > Yes, the definition is probably ok. I am referring to text elsewhere in the draft. > >> With respect to Q2, I agree that's why we made the sending of the simultaneous set optional. If the provider doesn't send the STS the consumer assumes that all captures in the CSE can be provided simultaneously. > > EVEN if the provider sends STS, I think a provider MUST be able to provide a CSE. I think this makes sense, but what to do if the simultaneous set conflicts? > In my opinion, the only use of STS is when one wants to simultaneously provide captures belonging to different CSE/CS. But, as I indicated earlier, in my opinion is would be better to indicate Simultaneous CSE Set. I disagree, because it may be feasible to provide *some* simultaneity but not be able to provide two complete CSEs simultaneously. Thanks, Paul > Regards, > > Christer > > > > > > On 28/02/2013 11:24 PM, Christer Holmberg wrote: >> >> Hi, >> >> A couple of initial comments: >> >> ------------------- >> >> Q1: Capture Scene and Capture Scene Entry editorial >> >> In a few places, there is text saying that "a Capture Scene includes >> one or more Capture Scene Entries". I think that is a little >> misleading, because it sounds like one uses one or more CSEs in order >> to describe a CS. >> >> But, as each single CSE describes the whole scene, I think the text >> should talk about CSEs providing alternatives for providing the CS. >> >> ------------------- >> >> Q2: Simultaneous Transmission Set >> >> We had a long discussion about this some time ago, and we never came >> to a conclusion. I know there is another thread about STSs also, and I >> will reply to that. >> >> But, I think that an endpoint shall always be able to simultaneously >> provide all captures within a given CSE. So, there is no need to >> explicitly advertise that the captures associated with a given CSE can >> be provided simultaneously. >> >> ------------------- >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Mar 1 03:28: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 9DCB121F88CF for ; Fri, 1 Mar 2013 03:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M15n9KNk-2YU for ; Fri, 1 Mar 2013 03:28:20 -0800 (PST) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1E21F8899 for ; Fri, 1 Mar 2013 03:28:20 -0800 (PST) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta10.emeryville.ca.mail.comcast.net with comcast id 6BUL1l0021HpZEsAABULVp; Fri, 01 Mar 2013 11:28:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([113.108.97.1]) by omta14.emeryville.ca.mail.comcast.net with comcast id 6BRz1l00201nDsp8aBS4MG; Fri, 01 Mar 2013 11:26:15 +0000 Message-ID: <51309048.6010507@alum.mit.edu> Date: Fri, 01 Mar 2013 19:26:00 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it> In-Reply-To: <512F47E1.9090600@unina.it> 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=1362137300; bh=EIaMWyxZSiS6OBeTNgVoUDiHDAtbVvfQnUoEobFzh0Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Kv9pUbm4A2p2wL5jlI3FX3S0v3LzAwztMn+mQva90aLbzV2luI4ENRvgYRo7mQ/7Q omW91X7Lr/KcTsf1VSJWDk+46NrMgBnr4EmMgWml/HmfSaayjTl6Fl7BFjMvf8y9YF 89pG3OY916LCJ75UUX9jwTrNwAOjK3cLKV34uTcExR1PkaOSs4sP/JRbyNDd6dOPht UNmlQ2AFgSWFKTMXYshukiOMujJHJ5B3sJirZOC6U2cZOO/moL6PJsavywSoRRlBy2 Mz85O7APJqBc8brqzM4qfC4AgquPZ7UbNvg2KhPVwPurkoTU9N5QhoUG4tKgUbqdnA h7EXM7GO9lBBQ== Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 11:28:20 -0000 On 2/28/13 8:04 PM, Roberta Presta wrote: > My proposal is, instead of listing all the captures, using capture scene > identifiers and capture scene entry identifiers, and building > simultaneous sets as: > - CSB, CSC, CSE3_A, CSE1_A > - CSB, CSC, CSE3_A, CSE2_A This is more concise, and may partially satisfy Christer :-) It does imply that the identifiers for CSs must be unique from those for CSEs. (There is a single namespace shared by both CS ids and CSE ids.) I haven't looked at the latest data model yet to see if that is guaranteed. Thanks, Paul From christer.holmberg@ericsson.com Sat Mar 2 07:18:51 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 7CC3421F84BD for ; Sat, 2 Mar 2013 07:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0vM-PzYQSJd for ; Sat, 2 Mar 2013 07:18:51 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D9C3D21F84B1 for ; Sat, 2 Mar 2013 07:18:49 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-ce-513218589c19 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 91.98.19728.85812315; Sat, 2 Mar 2013 16:18:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 16:18:47 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiOlViAgACHS4CAAYd9AIAB4kNi Date: Sat, 2 Mar 2013 15:18:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>,<51309048.6010507@alum.mit.edu> In-Reply-To: <51309048.6010507@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW6EhFGgwa31chb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx+v1qloIJ7BUz2vawNTCeYu1i5OSQEDCR uDrxKpQtJnHh3nq2LkYuDiGBQ4wSh3+vYoZwFjFKXNl0ByjDwcEmYCHR/U8bpEFEwFNix8cp zCC2sICDRMuvKawQcUeJVavmsUDYbhINk6ezg9gsAioSazZeAqvnFfCWuD33AVhcSKCZUeLi FTYQm1NAR+LI5P9MIDYj0EHfT60Bs5kFxCVuPZnPBHGogMSSPeeZIWxRiZeP/0E9oCix82w7 M0S9jsSC3Z/YIGxtiWULX0PtFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMbLnJmbmpJcb bWIExsLBLb9VdzDeOSdyiFGag0VJnDfc9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaK FMZD22Ll7y9Si3QwSxTq6drIvUDBl6kkzPiQmHNsSJd37G6VvmKhZz/8t8Zbiek+rprQqxTx b/6P+vsTVi96Wyj3sC37JP+HvPTew1MtOE4V6vdN2x1Tp+2j6bJo0/+H/2V6TnOJsz+Zd6kh +WtpzefXwR/ebyyLztw0L6VDXDGkeN7TYCWW4oxEQy3mouJEAFStyF1TAgAA Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 15:18:51 -0000 Hi, >> My proposal is, instead of listing all the captures, using capture scene >> identifiers and capture scene entry identifiers, and building >> simultaneous sets as: >> - CSB, CSC, CSE3_A, CSE1_A >> - CSB, CSC, CSE3_A, CSE2_A > > This is more concise, and may partially satisfy Christer :-) I'm listening :) >It does imply that the identifiers for CSs must be unique from those for >CSEs. (There is a single namespace shared by both CS ids and CSE ids.) I >haven't looked at the latest data model yet to see if that is guaranteed. Just for my clarification, what does it mean to indicate a CS? A CS does not have any captures. A CS is always represented by at least one= CSE, and the CSE contains captures. So, taking your example, does CSB indicate that I can provide ANY CSE assoc= iated with CSB, or that I can provide ALL CSEs associated with CSB? Regards, Christer From pkyzivat@alum.mit.edu Sat Mar 2 11:51:32 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 F415D21F855F for ; Sat, 2 Mar 2013 11:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.182 X-Spam-Level: X-Spam-Status: No, score=0.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DT8mMLIwq1-2 for ; Sat, 2 Mar 2013 11:51:27 -0800 (PST) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4613B21F849A for ; Sat, 2 Mar 2013 11:51:27 -0800 (PST) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta11.emeryville.ca.mail.comcast.net with comcast id 6jbq1l0021vN32cABjrTbc; Sat, 02 Mar 2013 19:51:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([207.239.114.206]) by omta22.emeryville.ca.mail.comcast.net with comcast id 6jp11l00W4TFMwX8ijp7tr; Sat, 02 Mar 2013 19:49:22 +0000 Message-ID: <513257AE.9000405@alum.mit.edu> Date: Sun, 03 Mar 2013 03:49:02 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>, <51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10F20D@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=1362253887; bh=z+o1jcOZPV5e4DFoUW9A6G8BqyPR2w4JO5W+4Bxhu30=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HV001iM/kKBUYN5lBwUio4CAbIV7B1jDU77G87Y+SkdTDOU15qX2yqM5TZ4A6KsC4 w0bvf02Zfn6xI8AWX0w4omBHPCWBXW+qDZzo6hX3m9eacC1t3EahFLuHRZ88O3yhmu eSt+9pBjJS+KFl2De2Lf+tqT5clNeOw7x2KRZK88RcHGsgv0+7NqZziNg/o6JlbkWt eRSTMPMFEWxwpWmCgZeSoBZG6vSXZCFuttZVWaPVrbNhDdEAiE0G3q7XE51MX6r+c9 KNh4D1J+jbDWwOwiS9jsq+2ZFwIUFoxmYIclfEXDlqDnLS50f3toFRYn44eTfvWuQM efcV3tl8eGFMg== Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 19:51:32 -0000 On 3/2/13 11:18 PM, Christer Holmberg wrote: > > Hi, > >>> My proposal is, instead of listing all the captures, using capture scene >>> identifiers and capture scene entry identifiers, and building >>> simultaneous sets as: >>> - CSB, CSC, CSE3_A, CSE1_A >>> - CSB, CSC, CSE3_A, CSE2_A >> >> This is more concise, and may partially satisfy Christer :-) > > I'm listening :) > >> It does imply that the identifiers for CSs must be unique from those for >> CSEs. (There is a single namespace shared by both CS ids and CSE ids.) I >> haven't looked at the latest data model yet to see if that is guaranteed. > > Just for my clarification, what does it mean to indicate a CS? > > A CS does not have any captures. A CS is always represented by at least one CSE, and the CSE contains captures. > > So, taking your example, does CSB indicate that I can provide ANY CSE associated with CSB, or that I can provide ALL CSEs associated with CSB? I was a little jetlagged when I wrote that. (Still am, so take this with a grain of salt.) I guess perhaps I misinterpreted Roberta. But what I was thinking of was being able to list CSEs and/or individual captures in a simultaneous set. And in spite of what I said before, that may not require the identities of both to be in the same namespace. It depends on how the XML is constructed. Thanks, Paul From christer.holmberg@ericsson.com Sun Mar 3 00:29:52 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 1CBD521F863B for ; Sun, 3 Mar 2013 00:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbmFgZTocHVQ for ; Sun, 3 Mar 2013 00:29:51 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 224A321F863A for ; Sun, 3 Mar 2013 00:29:50 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-13-513309fcaad1 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EF.C4.10459.CF903315; Sun, 3 Mar 2013 09:29:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 09:29:48 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiOlViAgACHS4CAAYd9AIAB4kNigAA8nQCAAOMVuw== Date: Sun, 3 Mar 2013 08:29:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10FCEB@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>,<51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se>, <513257AE.9000405@alum.mit.edu> In-Reply-To: <513257AE.9000405@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje4fTuNAgyO7DC32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj05Ie5oJFAhW//nUxNjCe5Oli5OSQEDCR aDjYzgJhi0lcuLeerYuRi0NI4BCjxNfDX9ghnEWMEh9+HASq4uBgE7CQ6P6nDWKKCGhITNqq BtLLLKAs8bVhExOILSzgINHyaworiC0i4CixatU8Fgg7TOLGi3+MIDaLgIrEw9Nv2UBsXgFv iafXWhkhVj1llNiwbjozSIJTQEfiUc9csAZGoOO+n1rDBLFMXOLWk/lMEEcLSCzZc54ZwhaV ePn4HyuErSix82w7M0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQt CxhZVjGy5yZm5qSXG25iBMbIwS2/dXcwnjoncohRmoNFSZw3zPVCgJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbG9NsnBDIbwr/qCce/eZjK5CB3siAxv9B/h4wg+wGFLtNj9V+KZ2YcMdA2 kf5+YtexVE1esdnv6/3u/d4/yXvlqqhUsw/Gj6cc+Zzm2rhoVqla+dFP9g3T/nAsDHD+POvt pNkeuakfrjGK8Pxcd+1el9yXibJHHwVU/OCU5Ltzi8sn6pnfC159JZbijERDLeai4kQAnqCy QV8CAAA= Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 08:29:52 -0000 Hi, >>>> My proposal is, instead of listing all the captures, using capture sce= ne >>>> identifiers and capture scene entry identifiers, and building >>>> simultaneous sets as: >>>> - CSB, CSC, CSE3_A, CSE1_A >>>> - CSB, CSC, CSE3_A, CSE2_A >>> >>> This is more concise, and may partially satisfy Christer :-) >> >> I'm listening :) >> >>> It does imply that the identifiers for CSs must be unique from those fo= r >>> CSEs. (There is a single namespace shared by both CS ids and CSE ids.) = I >>> haven't looked at the latest data model yet to see if that is guarantee= d. >> >> Just for my clarification, what does it mean to indicate a CS? >> >> A CS does not have any captures. A CS is always represented by at least = one CSE, and the CSE contains captures. >> >> So, taking your example, does CSB indicate that I can provide ANY CSE as= sociated with CSB, or that I can provide ALL CSEs associated with CSB? > > I was a little jetlagged when I wrote that. (Still am, so take this with > a grain of salt.) > > I guess perhaps I misinterpreted Roberta. > But what I was thinking of was being able to list CSEs and/or individual > captures in a simultaneous set. I can live with that :) We probably need to think about some rules for that, but one thing (based o= n your other reply to me): if I indicate support of CSE_1, then I don't thi= nk I should be allowed - within the same set - to list any captures associa= ted with CSE_1 in the same set. Because, CSE_1 already means that I can pro= vide all associated captures. Example: CSE_1 has the following captures: CS_1A, CS_1B and CS_1C CSE_2 has the following captures: CS_2A, CS_2B, CS_2C Allowed set: CSE_1, CS_2B, CS_2C <------ CS_2B and CS_2C are not associated with CSE_1= =20 NOT allowed: CSE_1, CS_1A <------ CS_1A is associated with CSE_1 >And in spite of what I said before, that may not require the identities >of both to be in the same namespace. It depends on how the XML is >constructed. Yes. Regards, Christer From christer.holmberg@ericsson.com Sun Mar 3 01:51:16 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 2BE7D21F8640 for ; Sun, 3 Mar 2013 01:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.247 X-Spam-Level: X-Spam-Status: No, score=-6.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64rqIwo1bQb7 for ; Sun, 3 Mar 2013 01:51:15 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E07EE21F857C for ; Sun, 3 Mar 2013 01:51:14 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-35-51331d11ebf8 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 52.8B.10459.11D13315; Sun, 3 Mar 2013 10:51:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 10:51:13 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Proposed: IETF-86 CLUE WG design team meeting Thread-Index: AQHOFUDAa0DuQTN7QkWbzUbkvRQEN5iTva8Y Date: Sun, 3 Mar 2013 09:51:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10FD64@ESESSMB209.ericsson.se> References: 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+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvja6QrHGgwesrbBb7T11mtvi8fz+z A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx5sofloIlfBXTr31ibGBcz93FyMkhIWAi 8ef7RhYIW0ziwr31bCC2kMAhRonD7YpdjFxA9iJGib1L/zJ3MXJwsAlYSHT/0wapERFwkrjw 8j1Yr7CAo8T0N9uYYeJbdx1ghLCNJK7f2McKYrMIqEgsXHAILM4r4C3x6s46RohdARI/tu8F m8MpEChx5MgisDmMQPd8P7WGCcRmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCnKahICixPJ+ OYhyHYkFuz+xQdjaEssWvmaGWCsocXLmE5YJjKKzkEydhaRlFpKWWUhaFjCyrGJkz03MzEkv N9zECIyDg1t+6+5gPHVO5BCjNAeLkjhvmOuFACGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M IbPtDU8fyfQNip3/dnK/+aXvR5jVLVQ5O9Omn1m2VuSE7K9thysPvv16TC7vgpvUod9KWxcF zira4czrFdJ600tl+5KUeM60Um127wiek83sp2pF939Zfk0k0uh777ytuxO/ztlVvK3dWSNp 0asivmmuZ0zTtxyc28y0523rg/kSDaLFrSvalViKMxINtZiLihMBuE9zElECAAA= Subject: Re: [clue] Proposed: IETF-86 CLUE WG design team 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: Sun, 03 Mar 2013 09:51:16 -0000 Hi, I realized that this conflicts with ECRIT, where I am going to present. However, my stuff in ECRIT is towards the end of the session, so it should = be ok. I can tell the ECRIT chairs that I will not be in the room for the f= irst hour. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Thursday, 28 February 2013 1:18 AM To: CLUE Subject: [clue] Proposed: IETF-86 CLUE WG design team meeting HI all, The doodle showed that all the times were okay. So, I just picked one that I thought would work the best - 13:00 on Wednesday, March 13. I will request a room and announce that once I know it (pending AD approval, of course). I do have a backup plan. Thanks, Mary. On Tue, Feb 26, 2013 at 5:09 PM, Mary Barnes w= rote: > Hi folks, > > As a reminder, we have outstanding doodles (which closed on Feb. 18th) > for both a CLUE WG design team meeting between our sessions: > http://www.doodle.com/nqrdkdes42aaur8n > (Note: I think the time for the breakfast is off - it should be 7:30 > Orlando time). > > And, a CLUE Dinner: > http://www.doodle.com/xaqdxztxrpt8h6wq > > I would like to close both polls by the end of the day tomorrow, so I > can request a room and book a place for dinner (we are in Orlando > during one of the peak times for Disney). Right now only 6 have > responded to the design team meeting and 6 for the dinner. It's a very > nice set of 6 for each but I think we need more for a productive > meeting and we'd certainly welcome others for dinner ;) > > Mary. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Sun Mar 3 02:38:00 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 A68D321F8654 for ; Sun, 3 Mar 2013 02:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPHqekhty7up for ; Sun, 3 Mar 2013 02:38:00 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id BB8EB21F8652 for ; Sun, 3 Mar 2013 02:37:59 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so3236501eek.20 for ; Sun, 03 Mar 2013 02:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=+uY4tbojru0/8S2LbxsQMzVVJQ2Iuj9c4OBJyXTMfE4=; b=0B5dpfSTUXgxXAQA5EuDovRxevaMNmgIp9fmPf+Zb9+M1r7pjfwmNKlTn7N0DJUcnJ DqpWSkIJy9Z0VyJp12pNZjsxO8BfQxEdHSsxF8YxFwrU8kmNvmbwMVeDAMGu5+4vx+3R IeTlBkpl8NhkETocuFhqdQa96Spu1wULQ6PxvMffiNA/LneWn3KONXtzLo8gLCUjzo7d JRveioAv1TqbaswmiPv5yATDYrB1VrUSB24ofhX2i46cTvrGNX0EY+Wj5PibJWsIbsjj VDaqn0U0ojeDgKBPvGPONlKPuj/3VgEIYE8+fScCaRblit4Tqd/DUMYV0EpvoBMCPWxG p8Ww== X-Received: by 10.14.207.200 with SMTP id n48mr47124417eeo.4.1362307078864; Sun, 03 Mar 2013 02:37:58 -0800 (PST) Received: from RoniE (bzq-79-176-219-11.red.bezeqint.net. [79.176.219.11]) by mx.google.com with ESMTPS id q5sm26582569eep.11.2013.03.03.02.37.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 03 Mar 2013 02:37:57 -0800 (PST) From: "Roni Even" To: "'Robert Hansen'" , References: <5122892C.6000804@cisco.com> In-Reply-To: <5122892C.6000804@cisco.com> Date: Sun, 3 Mar 2013 12:34:47 +0200 Message-ID: <02af01ce17fa$bc2cf990$3486ecb0$@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: AQEpp/ZwKsj+eqEfEVVtpi5barBakpnco3dA Content-Language: en-us Subject: Re: [clue] draft-hansen-clue-sdp-interaction-00 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: Sun, 03 Mar 2013 10:38:00 -0000 Hi Rob, I wrote a similar draft http://tools.ietf.org/html/draft-even-clue-sdp-clue-relation-01 and my conclusion was Conclusion - except for the maxWidth and maxHeight there is no problem between the SDP and CLUE encoding values as long as SDP attributes are used as receiver capabilities and the relation between the two protocols is defined. Changing SDP values will not require a change in CLUE advertisement or configuration and vice versa since these parameters signal maximum values and not exact values. For the maxWidth and MaxHeight it has to do with using RFC6236 as image attribute. As for band width one issue I mention is using RTCP TMMBR for changing the bw. This will need to be inline with both the SDP and CLUE values. Still in section 5 you say "If updates to both negotiations are required for a new stream to be added, then the new stream will not be available until both renegotiations are complete " I was wondering how is it known to both sides. This was an open issue in our discussion. Another question is on "A cost of this is that endpoints will now need to deal with the fact that CLUE messages may contain parameters exceeding those negotiated in SDP, or referencing SDP content that does not exist" Does it mean that we can add an RTP stream without signaling? This will fail for intermediaries Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen Sent: 18 February, 2013 10:04 PM To: clue@ietf.org Subject: [clue] draft-hansen-clue-sdp-interaction-00 Hi all, I've posted a new draft which will hopefully have a relatively short lifespan on the topic of the interactions between CLUE signalling and SDP - as we've discovered when we've tried to define things like call flows a lot of the different aspects are dependant on each other, making it hard to make a decision. I picked a couple of points that I believe aren't so entangled. Some of these things in it are hopefully uncontroversial but haven't always been documented yet, others are likely to provoke more disagreement. There's no attempt in the draft at defining the SDP or CLUE messages, the draft merely discusses what information is needed in each and how they should interact. For -01 I hope to add some diagrams to better illustrate what's going on. Rob _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From roberta.presta@unina.it Sun Mar 3 10:50:54 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 2152421F87FB for ; Sun, 3 Mar 2013 10:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.189 X-Spam-Level: * X-Spam-Status: No, score=1.189 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_ILLEGAL_IP=1.908] 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 6RditIvS8ozk for ; Sun, 3 Mar 2013 10:50:50 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id A3B9A21F87F6 for ; Sun, 3 Mar 2013 10:50:46 -0800 (PST) Received: from [127.0.0.1] (2-237-80-133.ip237.fastwebnet.it [2.237.80.133]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r23IoTRh020749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Mar 2013 19:50:40 +0100 Message-ID: <51339B72.6070203@unina.it> Date: Sun, 03 Mar 2013 19:50:26 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>, <51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130303-0, 03/03/2013), Outbound message X-Antivirus-Status: Clean Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Mar 2013 18:50:54 -0000 Hi Christer, Il 02/03/2013 16:18, Christer Holmberg ha scritto: > >>> My proposal is, instead of listing all the captures, using capture scene >>> identifiers and capture scene entry identifiers, and building >>> simultaneous sets as: >>> - CSB, CSC, CSE3_A, CSE1_A >>> - CSB, CSC, CSE3_A, CSE2_A >> So, taking your example, does CSB indicate that I can provide ANY CSE associated with CSB, or that I can provide ALL CSEs associated with CSB? Listing a capture scene identifier like CSB in a simultaneous set should mean the provider is able to send simultaneously all the captures within the capture scene entries associated with that capture scene. Or, at least, that was what I had in mind. It is in line with the current definition of the simultaneous sets (Simultaneous transmission sets are expressed as sets of the Media Captures that could physically be transmitted at the same time). Regards, Roberta From pkyzivat@alum.mit.edu Sun Mar 3 20:43: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 4245921F8820 for ; Sun, 3 Mar 2013 20:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[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 WH44O0cDk5kJ for ; Sun, 3 Mar 2013 20:43:39 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id A3D4721F8756 for ; Sun, 3 Mar 2013 20:43:35 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta05.westchester.pa.mail.comcast.net with comcast id 7GRU1l0020ldTLk55GjZne; Mon, 04 Mar 2013 04:43:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 7GjZ1l00D3ZTu2S3QGjZDF; Mon, 04 Mar 2013 04:43:33 +0000 Message-ID: <51342675.8070603@alum.mit.edu> Date: Mon, 04 Mar 2013 12:43:33 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>, <51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se>, <513257AE.9000405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10FCEB@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10FCEB@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=1362372213; bh=5xU5kZAmOIFPzVAE27Vrme8iIJ6fkZ3MwSpI26NHznM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JM4M8bAXcaQ3rxPDdrcbBaZoHggwd/TLLn8ivzZibdvYVoWJRpiIdKzCiSQogyBXi UrpgzUm/BsTMhzsRycNucCV/Ztng61+ctK0aEIzBllnSMNnPr4Eq9Z6MmTxXBa4oK7 cZ+IoOr9C/CEHUiL4Eil6XHbCiDCEZz+8q1wpmO6xawkNZ2baTG3VBJG05AGKeVSRp eZVYqfyqQihYfvjoq+dzVcbFn070g9/tuUmtGYJ6vsSEtCbIO/CPK7k46aePfhJYaK pZ3KIWB9R/TdC1mhTrDa87D8aP7IShCgxblho/YkXojgJHISGyAYryjPodfP0wyBHD 3ewJpGVasmkCQ== Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 04:43:40 -0000 On 3/3/13 4:29 PM, Christer Holmberg wrote: >> I guess perhaps I misinterpreted Roberta. >> But what I was thinking of was being able to list CSEs and/or individual >> captures in a simultaneous set. > > I can live with that :) > > We probably need to think about some rules for that, but one thing (based on your other reply to me): if I indicate support of CSE_1, then I don't think I should be allowed - within the same set - to list any captures associated with CSE_1 in the same set. Because, CSE_1 already means that I can provide all associated captures. > > Example: > > CSE_1 has the following captures: CS_1A, CS_1B and CS_1C > CSE_2 has the following captures: CS_2A, CS_2B, CS_2C > > Allowed set: > > CSE_1, CS_2B, CS_2C <------ CS_2B and CS_2C are not associated with CSE_1 > > NOT allowed: > > CSE_1, CS_1A <------ CS_1A is associated with CSE_1 This is just a matter of philosophy about errors. Specifying a single capture more than once in a simultaneous set is clearly redundant and unnecessary, but also harmless. I don't feel strongly whether that should be considered an error. Thanks, Paul From pkyzivat@alum.mit.edu Sun Mar 3 21:13: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 898C421F8846 for ; Sun, 3 Mar 2013 21:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.162 X-Spam-Level: ** X-Spam-Status: No, score=2.162 tagged_above=-999 required=5 tests=[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 OtQCMrZZl5kC for ; Sun, 3 Mar 2013 21:13:33 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id E58E721F8742 for ; Sun, 3 Mar 2013 21:13:32 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7GwX1l0060Fqzac53HDYxo; Mon, 04 Mar 2013 05:13:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 7HDX1l00N3ZTu2S3UHDY8q; Mon, 04 Mar 2013 05:13:32 +0000 Message-ID: <51342D7A.4020109@alum.mit.edu> Date: Mon, 04 Mar 2013 13:13:30 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Roberta Presta References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>, <51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> <51339B72.6070203@unina.it> In-Reply-To: <51339B72.6070203@unina.it> 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=1362374012; bh=4maqsqPBLQsnaarilHQORCT1w5bHbPt7GIGtWheeeHo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=s7svzpj/PqcuLR52cvbxt1sxaVpgrJrfMaeJnJPszxN41akZi6s8dEnS1JAAy6H1u uDdfqivL+pF5a4BoMlwMBPjIyDEVupMMEDiih49Q8Zf6i6X5ndADlRldgM+J/RR0s6 8fFHdokmD9XwhrxehgpchLwxH71wm99udpaI07BLZjU5EyJP0KdkTOQo4vWfTOPvn8 CKnjnW5eJ4NKvaafKUkxUJ+LCR6e1YVIAE35AXjstSGVApipkR+CHZfKC5kdu15L5h /aviXszhUiKbERYeV3UIs70O8MyNoduI0veDDyYgRDTkJHN4CLw4AEhABQBfYTIPxh iKv9bWOijBhTw== Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 05:13:33 -0000 On 3/4/13 2:50 AM, Roberta Presta wrote: > Hi Christer, > > Il 02/03/2013 16:18, Christer Holmberg ha scritto: >> >>>> My proposal is, instead of listing all the captures, using capture >>>> scene >>>> identifiers and capture scene entry identifiers, and building >>>> simultaneous sets as: >>>> - CSB, CSC, CSE3_A, CSE1_A >>>> - CSB, CSC, CSE3_A, CSE2_A >>> So, taking your example, does CSB indicate that I can provide ANY CSE >>> associated with CSB, or that I can provide ALL CSEs associated with CSB? > > Listing a capture scene identifier like CSB in a simultaneous set should > mean the provider is able to send simultaneously all the captures within > the capture scene entries associated with that capture scene. > Or, at least, that was what I had in mind. > It is in line with the current definition of the simultaneous sets > (Simultaneous transmission sets are expressed as sets of the Media > Captures that could physically be transmitted at the same time). > Regards, Ah, ok - that makes sense. So referencing a CSE means all the captures in it, and referencing a CS means all the CSEs in it. With that interpretation, then referencing a CS could implicitly reference a single capture more than once. So a corollary is that referencing a single capture more than once is not an error. This does make a lot very concise to describe some common kinds of simultaneous sets. Thanks, Paul From christer.holmberg@ericsson.com Mon Mar 4 01:04:51 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 9F66F21F8880 for ; Mon, 4 Mar 2013 01:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 4Kb91TTxb8oJ for ; Mon, 4 Mar 2013 01:04:51 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AC32021F8871 for ; Mon, 4 Mar 2013 01:04:50 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-2b-513463b174cf Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A7.9C.32353.1B364315; Mon, 4 Mar 2013 10:04:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 10:04:49 +0100 From: Christer Holmberg To: Paul Kyzivat , Roberta Presta Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiOlViAgACHS4CAAYd9AIAB4kNigAG+kwCAAK4VAIAAUHYg Date: Mon, 4 Mar 2013 09:04:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1106B1@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>,<51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> <51339B72.6070203@unina.it> <51342D7A.4020109@alum.mit.edu> In-Reply-To: <51342D7A.4020109@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+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7GZJNAgz3TdS32n7rMbLFiwwFW i1efqxyYPf6+/8DksWTJTyaPH1ueMgUwR3HZpKTmZJalFunbJXBlnNm5n7FgEV/Fu2kJDYwr ubsYOTkkBEwkZv95zghhi0lcuLeerYuRi0NI4BCjxNblPVDOIkaJzR9+ATkcHGwCFhLd/7RB GkQEQiSWnOtjAbGZBZQlvjZsYgKxhQUcJFp+TWGFqHGUWLVqHguEHSWx5/VZsBoWARWJ2c3f 2EBsXgFvieP7l7JD7Gpmkrg+4RRYM6eAjsSfTwfAihiBrvt+ag0TxDJxiVtP5jNBXC0gsWTP eWYIW1Ti5eN/rBC2osTV6cuh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzUIydhaSlllI WmYhaVnAyLKKkT03MTMnvdx8EyMwag5u+W2wg3HTfbFDjNIcLErivOGuFwKEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MC7cclqF7/jhtRrefe72C1q0JyjeyBZ9E71ZNOnolc1F+4z8TNqz /kXyWopu3fzpOCcbe49247avs0SPVVfmRWdUdC1d8NiQ96Daotf/HvFy6i85YqMu2xFYfmFl jqGB2uy4ULsnEikVK745W+k8dlXYWafDJfP/l9xmXvtDikovag4plkxZqcRSnJFoqMVcVJwI AMqqok9oAgAA Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 09:04:51 -0000 Hi, >>>>> My proposal is, instead of listing all the captures, using capture=20 >>>>> scene identifiers and capture scene entry identifiers, and building=20 >>>>> simultaneous sets as: >>>>> - CSB, CSC, CSE3_A, CSE1_A >>>>> - CSB, CSC, CSE3_A, CSE2_A >>>> So, taking your example, does CSB indicate that I can provide ANY=20 >>>> CSE associated with CSB, or that I can provide ALL CSEs associated wit= h CSB? >> >> Listing a capture scene identifier like CSB in a simultaneous set=20 >> should mean the provider is able to send simultaneously all the=20 >> captures within the capture scene entries associated with that capture s= cene. >> Or, at least, that was what I had in mind. >> It is in line with the current definition of the simultaneous sets=20 >> (Simultaneous transmission sets are expressed as sets of the Media=20 >> Captures that could physically be transmitted at the same time). >> Regards, > > Ah, ok - that makes sense. > > So referencing a CSE means all the captures in it, and referencing a CS m= eans all the CSEs in it. With that interpretation, then referencing a CS co= uld implicitly reference a single capture more than once. So a corollary is= that referencing=20 > a single capture more than once is not an error. I agree. If you reference a CS, and some capture is used in multiple associ= ated CSEs, it means that you are able to provide multiple "instances" of th= e capture - one for each CSE where it is used. The same thing would apply if you reference a CSE, and a capture within it:= it means you are able to provide two "instances" of the capture. So, while I can't think of any use-case at the moment, I agree that we shou= ld not consider it an error case. But, we need to make sure it's clearly do= cumented :) Regards, Christer From mary.ietf.barnes@gmail.com Mon Mar 4 08:07:51 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 20B2421F8CA1 for ; Mon, 4 Mar 2013 08:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 6nPLT3jjJUuS for ; Mon, 4 Mar 2013 08:07:50 -0800 (PST) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7D46D21F8A3D for ; Mon, 4 Mar 2013 08:07:45 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id 1so3820897qee.16 for ; Mon, 04 Mar 2013 08:07:44 -0800 (PST) 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 :content-type; bh=snILIU2yJMipD7+t3NXyTg6OfwXOA5ucPEZs+9mAAZc=; b=wnQFira2jLdkTm7QfEy5yQ5p07pyD4nmCCKbrRoOWrvlw8jgEmIeLA17VaHhUW69pR 5NWMOVPsMDmOKZDYRHbRje4wqZ5VI5srbnUz1CqtFWsHwh5YPfNdpqs028FF/nESQHPJ oQ0aBeCFQi9wCjQsuVM6I+OvW82Gf0UBbzEHihwTYckDiRvc8zXiibDNQbHDM+4WOA84 LWgYc2Zivgtwu8wCtwr5fOpfmZ0Fz1J4yOFGhUHk4fYZc7Fz8fCr0jdcQUSpzSUhmJkY PMGpRR0S/VtBW//T0epkEt1Z+DCieh7k/mBZ2RBAI54P1ZP3bpoBg+SQMrZ8bG3R5snQ 88/Q== MIME-Version: 1.0 X-Received: by 10.49.116.235 with SMTP id jz11mr8247649qeb.39.1362413264816; Mon, 04 Mar 2013 08:07:44 -0800 (PST) Received: by 10.49.24.130 with HTTP; Mon, 4 Mar 2013 08:07:44 -0800 (PST) Date: Mon, 4 Mar 2013 10:07:44 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] CLUE Design Team meeting on for today - March 4th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:07:51 -0000 Note, we are going over details and plans for IETF-86. Mary From mary.ietf.barnes@gmail.com Mon Mar 4 08:36: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 11BA221F8C9D for ; Mon, 4 Mar 2013 08:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 G+sJh05OQI0J for ; Mon, 4 Mar 2013 08:36:51 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id D68D521F8BEC for ; Mon, 4 Mar 2013 08:36:50 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id g10so1276231qah.18 for ; Mon, 04 Mar 2013 08:36:50 -0800 (PST) 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 :content-type; bh=MKB2b2HKi0tI+NhGLKK7JbgRrWo/+vGjcDiskt+bIJM=; b=b3uo/2ZjExc/n7Z4jt14+1LcYRO+pjGaINr7aMKQvM35DMJwnwQ/AJnyWGkC8VIjSD 2RjnhahxfxDpprlnRuHkzR6UCtUl2AkIwxk31rpizeia7zd3rrtsCwMOP+MbFeXpC0IU rbhlOHCenNzeDEw5UEr3glbMTGfxgziEkaTOI+5JuwQW3JrVb81Nc5CUnlCl4Ef1kV1O BiKR5PURNp+jyf5m3O4KZj1HnzovaUZpqCZvY3FUC5+Jq2d+0axIg0W+zyNcEd/ySRJh ZgeDDqLC7TZ28fWGcx+LG3l28YswsomjQ7TAd1wbA06zXx/yLvWL/4mEyv4gIoB+cNQ8 CSsw== MIME-Version: 1.0 X-Received: by 10.229.171.3 with SMTP id f3mr7391408qcz.41.1362415010360; Mon, 04 Mar 2013 08:36:50 -0800 (PST) Received: by 10.49.24.130 with HTTP; Mon, 4 Mar 2013 08:36:50 -0800 (PST) Date: Mon, 4 Mar 2013 10:36:50 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] RTP grouping taxonomy draft X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:36:55 -0000 Hi all, Please note that this is a very important document applicable to the CLUE signaling solution that folks should be familiar with and will help set the context for our some of our discussions in Orlando: http://www.ietf.org/id/draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt Regards, Mary From christer.holmberg@ericsson.com Mon Mar 4 10:32:44 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 6814F21F8E2A for ; Mon, 4 Mar 2013 10:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 1nm+abp8FjDH for ; Mon, 4 Mar 2013 10:32:43 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF8C21F8E28 for ; Mon, 4 Mar 2013 10:32:43 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-5a-5134e8cac1e1 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F8.F9.32353.AC8E4315; Mon, 4 Mar 2013 19:32:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 19:32:42 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] CLUE Design Team meeting on for today - March 4th Thread-Index: AQHOGPJvZEE4k7vEpEu6TT5BImNDjJiV20hc Date: Mon, 4 Mar 2013 18:32:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B110F5D@ESESSMB209.ericsson.se> References: 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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6pFyaBBr97dSz2n7rMbPF5/35m ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj8pU/zAXrWSq+vrnE2sB4ibmLkZNDQsBE 4uXUtVC2mMSFe+vZuhi5OIQEDjFKvH/6AMpZxCjRdnQ7UxcjBwebgIVE9z9tkAYRASeJCy/f s4DYwgKuEh0LPrNCxN0kXrf0M0LYRhLb9zwDq2ERUJE4dfAEE4jNK+At8aD9GViNkECAxL9/ B8BqOAUCJSZO3g9mMwId9P3UGrB6ZgFxiVtP5jNBHCogsWTPeaijRSVePv7HCmErSuw8284M Ua8jsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjOy5iZk56eXm mxiBsXBwy2+DHYyb7osdYpTmYFES5w13vRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdE4 eXtp2nTTvklbjA4H1RlHVpiK5jnM3nY4yFXBeG+Y58pFMhHCz47e/durVmAaxZdnFX14o1TK 3x9nIrZefLtrmu08Zh31HeX/Lxzs9Z69LTEuy3ae8Ld/K4T5Jl/MtQ+c6WbyKvedJ1sVv8VF iTXfBaIUSm8+6t7MtuZt7YrYje0HxGRn2iixFGckGmoxFxUnAgD+qzOgUwIAAA== Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 18:32:44 -0000 Hi, Due to a personal issue, I wasn't able to attend. Sorry for that. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Monday, 04 March 2013 6:07 PM To: CLUE Subject: [clue] CLUE Design Team meeting on for today - March 4th Note, we are going over details and plans for IETF-86. Mary _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Mon Mar 4 15:41:58 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 20F7F11E80E0 for ; Mon, 4 Mar 2013 15:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QduHLDGsQ2ZP for ; Mon, 4 Mar 2013 15:41:57 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7B611E80D7 for ; Mon, 4 Mar 2013 15:41:57 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::5efe:10.236.0.200]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 4 Mar 2013 15:06:52 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 4 Mar 2013 15:06:52 -0800 Thread-Topic: [clue] New framework I-D posted Thread-Index: Ac4S5afMGUb/r48GRmqT7rJpVVitVQGP4JLQ Message-ID: <9C23AB934B394845A7B228239B6EAF41539E39@CRPMBOXPRD01.polycom.com> References: <512A9240.3040800@alum.mit.edu> In-Reply-To: <512A9240.3040800@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] New framework I-D posted X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 23:41:58 -0000 Hi Paul, My comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Sunday, February 24, 2013 5:21 PM > To: clue@ietf.org > Subject: Re: [clue] New framework I-D posted >=20 > Stephan, >=20 > Thanks for doing this. I think the document is much improved. > I have a few comments: >=20 > Definition of Encoding: >=20 > It is given as: "Encoding or Individual Encoding: a set of parameters > representing a way to encode a Media Capture to become a Capture > Encoding." >=20 > This is fine as far as it goes, but I don't think it captures the full se= mantics. > According to this definition, I would expect that I could apply an encodi= ng to a > number of captures concurrently, producing a number of capture encodings. > But section 7.1 says an encoding can only handle one capture at any given > time. That part of the meaning is lacking in the definition. A suggestion= : >=20 > "Encoding or Individual Encoding: a resource that may be used to encode a > Media Capture as a Capture Encoding, and a set of parameters describing > how the encoding will be performed." [Duckworth, Mark] either way is okay with me. > In section 4: >=20 > Edt. note: The editors are not sure whether the mentioned > overloading of established RTP channels using only CLUE messages is > possible, or desired by the WG. If it were, certainly there is > need for specification work. One possible issue: a Provider which > thinks that it can switch, say, a audio codec algorithm by CLUE > only, talks to a Consumer which thinks that it has to faithfully > answer the Providers Advertisement through a Configure, but does > not dare setting up its internal resource until such time it has > received its authoritative O/A exchange. Working group input is > solicited. >=20 > It was my understanding that we were not advocating doing anything that i= s > contrary to the negotiated SDP. (E.g. using a codec not mentioned in the > SDP.) But there are still plenty of changes that could potentially be mad= e > without violating the current SDP. E.g. selecting a new capture-encoding = that > uses an m-line that is already compatible. [Duckworth, Mark] I agree, Paul. If this is what the group wants, the fram= ework document should clearly say CLUE devices follow all SDP O/A rules. S= hould we also refer to some specific RFCs? =20 >=20 > Section 6.2: >=20 > In more > complex systems, the use of additional Capture Scenes is also > sensible. For example, a three camera room may advertise two > Capture Scenes involving live video, one including only the center > camera (and associated audio), the other involving all three > cameras (and associated audio). >=20 > I'd like to hear more explanation of why this if a reasonable thing to > advertise. It doesn't seem reasonable to me, since all of these things ar= e > spatially related. [Duckworth, Mark] I agree. I'm not sure what happened here. Sounds like i= t might be confusing Capture Scenes with Capture Scene Entries. I'll check= with Stephan and Andy about the intent of this. > I have another question related to this section, but unrelated to the rec= ent > changes: >=20 > We have structured things so that audio and video scene entries are > independent - for each scene you need to choose one of each. But isn't it > possible that some combinations don't make sense? For instance if you > chose site switching for video then you should perhaps also choose site > switching for audio. >=20 > This would be clearer if scene entries contained captures of all media ty= pes. > But I realize doing that may greatly increase the number of entries. >=20 > Section 6.2.2: >=20 > While it makes sense to outsource the detailed attributes here, IMO it is= NOT > ok to defer the definition of switching and composition to the data model= . > There should be a discussion of the concepts of that *somewhere*, and I > can't think of a better place than the FW. For instance, the difference > between site switching and segment switching, and the difference between > switching and composition. (And of course that these have some difference= s > between audio and video.) [Duckworth, Mark] I'm not sure exactly where to draw the line about which t= hings go in which document. Site switch and segment switch description act= ually came from the use case document, we just repeated it in the framework= . Are you suggesting we just keep in the framework some of the text about = switching and composition that was already in the framework? And not move = so much of it to another document? > Section 8: >=20 > IMO a small bit of this content could be deferred to the data model: >=20 > Each Capture has an Encoding Group attribute. The value of this > attribute is the encodeGroupID for the Encoding Group with which it > is associated. [Duckworth, Mark] I agree > Section 9: >=20 > Edt. Note: The editors solicit input from the working group as to > whether or not a Consumer must respond to every Advertisement with > a new Configure message. >=20 > I propose that we decide this as part of defining the signaling, and then > reflect the outcome here. (Or maybe just don't mention it here.) [Duckworth, Mark] I agree > OPEN ISSUE >=20 > We have structured things so that audio and video scene entries are > independent - for each scene you need to choose one of each. But isn't it > possible that some combinations don't make sense? For instance if you > chose site switching for video then you should perhaps also choose site > switching for audio. >=20 > This would be clearer if scene entries contained captures of all media ty= pes. > But I realize doing that may greatly increase the number of entries. >=20 > Thanks, > Paul (as individual) > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Mon Mar 4 17:11:39 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 7D5B711E80D7 for ; Mon, 4 Mar 2013 17:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 Z66PxKkokk30 for ; Mon, 4 Mar 2013 17:11:38 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC7C11E80AE for ; Mon, 4 Mar 2013 17:11:38 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::5efe:10.236.0.200]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 4 Mar 2013 17:11:37 -0800 From: "Duckworth, Mark" To: Christian Groves , CLUE Date: Mon, 4 Mar 2013 17:11:37 -0800 Thread-Topic: [clue] New framework I-D posted Thread-Index: Ac4Ve+c1qCeOmtmZTK+oJbuBaLrgXADs2YOw Message-ID: <9C23AB934B394845A7B228239B6EAF41539E72@CRPMBOXPRD01.polycom.com> References: <512EF700.2080207@nteczone.com> In-Reply-To: <512EF700.2080207@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] New framework I-D posted 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, 05 Mar 2013 01:11:39 -0000 Hi Christian, Thanks for the feedback. Comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Thursday, February 28, 2013 1:20 AM > To: CLUE > Subject: Re: [clue] New framework I-D posted >=20 > Hello all, >=20 > The latest version looks pretty good, I've reviewed it and have the follo= wing > comments/questions. >=20 > Section 1, Pg.3 bullet (3) - It talks about "chosen by operator" perhaps = as the > next part talks about "consumer" it should say "chosen by provider". [Duckworth, Mark] I'm not sure what you mean. Are you talking about page 4= , paragraph numbered (2)? What do you suggest changing? > Section 1, Pg.3 bullet (3) - Simultaneous capture sets are actually above= the > capture scene description. Not part of the capture scene description. Thi= s is > due to the ability to indicate simultaneity requirements between all capt= ure > scenes in an advertisement. i.e. from > v8 "These simultaneous set constraints apply across > all the captures scenes in the advertisement." [Duckworth, Mark] I think it should just say "Simultaneous capture sets are= discussed in section 6.3", removing the incorrect part about being part of= a Capture Scene. > Section 1, Pg.3 bullet (5) - Why do we have the "sales pitch" :-) for RTP > multiplexing in motivation for CLUE? Isn't the key point that CLUE allows= for > the possible reduction of RTP flows? >=20 > Section 3 Advertisement: Is this missing description of the aspect of "ca= pture > scenes" and "captures" etc? The definition seems to on the stream where > the importance of the CLUE advertisement is really to signal the interrel= ation > between the different media captures/streams. [Duckworth, Mark] "describing specific aspects of the content of the media"= is referring to the Captures and Capture Scene information. That's how I = read it anyway. > General: The framework pretty much ties Capture/Capture encoding to RTP > only. Thinking out aloud could this be a restriction when considering cap= tures > relating to presentations? [Duckworth, Mark] I believe the scope of all this is limited to media strea= ms over RTP. > General: Text capture: According to our definitions CLUE support Text > captures. i.e. Media indicates the possibility of timed text, A media cap= ture > indicates that its the source of "media". We also talk about streams bein= g > RTP. Sect 6.3 also talks about captures of a particular type (audio, vide= o, > text). If we are supporting it then we may be a "Text Capture" (TC). This= may > be an issue for Orlando. [Duckworth, Mark] I agree we should include text, and possibly other types = of media but I don't have any specific examples. Maybe this issue is a mor= e for the data model, to make sure it doesn't exclude other media types tha= t go over RTP? > Section 4 Figure: In the signalling document it shows ACKs to the > Advertisement and Configure messages. Do we want to show those in the > framework or at least say for brevity acknowledgements aren't shown? [Duckworth, Mark] I think after we get a somewhat stable signaling document= we should make sure all the documents are consistent. > Section 5: With respect to the coordinate system and the origin. We say t= hat > the location of the origin is up to the provider's choosing. Would it be > beneficial to suggest a location for it? > > Section 6.1.1: It says that capture attributes provide "static" > information? What is meant by static here? Is it for the life of the CLUE > association. Static until the next Advertisement is sent? I suggest delet= ing it. [Duckworth, Mark] I think anything can change from one advertisement to the= next, so I agree we should delete the word "static". > Section 6.1.1: I'd prefer not to outsource the definitions of these attri= butes > to the data model. Part of the framework is to understand what this > information is used for. [Duckworth, Mark] Seems like we need more discussion on where to draw the l= ine between what goes in framework and what goes in the data model. =20 > Section 6.1.1: Area of capture: for consistency we should probably use > "bottom camera left", "top camera right", etc... [Duckworth, Mark] I agree > Section 6.2 Pg.19 Para.4: I'm not sure this reflects the discussions we'v= e had > on the list. It basically says says that the consumer can do what ever it= likes. I > thought there was some agreement that the consumer SHOULD chose a CSE > and that these were alternate representation of the entire scene (at leas= t > according to the scene definition). Section 6.3 mentions choosing only on= e > CSE. [Duckworth, Mark] Yes, the Consumer can choose whatever it wants, subject t= o constraints of the advertisement. Section 6.3 says "... the Consumer sho= uld choose one Capture Scene Entry for each media type, but may choose indi= vidual Captures based on the Simultaneous Transmission Sets." I think the = framework is saying what we agreed on the list. But maybe not clearly enou= gh? Do you have a specific suggestion? > Section 6.2.1: Like above I think its worth having some description in th= e > framework document. You should need to look into two documents to get > the gist of what CLUE is doing. >=20 > Section 6.2.1 Area of scene: If this is specified I take it that it must = be greater > than or equal to the outer extents of the individual captures? If it was = smaller > what would it mean? [Duckworth, Mark] Yes, I think it should be greater than or equal to the ou= ter extents of the individual captures. > Section 6.2.2: Should the scene switch policy be at a Capture scene level= ? For > example if we allow the consumer to cherry pick captures from different > CSEs what happens? Are the capture only related to a CSE switched togethe= r > or all captures related to the scene switched? [Duckworth, Mark] Good question. Related to Paul's question about picking = different CSEs for different media types, which could have different values= for the scene-switch-policy. > Section 7.1 Pg26.: We can probably remove "Clue-protocol internal > information" from the list of video codec specific parameters. [Duckworth, Mark] I agree that doesn't add any value here. Specifics would= be in the data model, I think. > Section 8. : It says that every capture is associated with an encoding gr= oup. > Does that mean a provider is REQUIRED to provide maximum the various > maximum information? I couldn't find any text which suggests sending of > encoding parameters is optional. [Duckworth, Mark] Yes, my understanding is it is required. > Section 9. pg. 32 para.4: Not sure that each Advertise is acknowledged by= a > Configure. Acknowledge of the receipt of a message and configuration coul= d > be separate. [Duckworth, Mark] The intent is to say something like the Consumer must sen= d a new Configure in response to receiving an Advertisement. Does that ma= ke more sense? I agree this could be separate from acknowledging receipt o= f the Advertisement. > Section 10.: It is envisaged that CLUE could support non-RTP streams in t= he > future? [Duckworth, Mark] I believe the scope of all this is limited to media strea= ms over RTP. I don't recall hearing anybody talk about expanding to non-RT= P streams in the future. > Section 11.1.1 Fig. : Nit - the figure has D but the text talks about 'd'= . >=20 >=20 >=20 > Regards, Christian >=20 >=20 >=20 >=20 >=20 > On 22/02/2013 10:27 AM, Stephan Wenger wrote: > > Hi, > > Version 9 of the framework I-D is out. Many editorial changes and > > cleanups, limited new substance. Included are a number of editor's > > notes with questions to the WG, mostly in the context of the ongoing > > signaling discussion (so we will probably not be able to address those > > questions immediately). > > See (some of) you in hellhole Orlando. > > Stephan > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Mar 4 21:27: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 A414821F8754 for ; Mon, 4 Mar 2013 21:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esh4zAlsSlm6 for ; Mon, 4 Mar 2013 21:27:18 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 6C31621F874F for ; Mon, 4 Mar 2013 21:26:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgDADWANVF20Yi3/2dsb2JhbAANN8JMBAMBgR2DEgEBAQMBAQEBJBEbGwoRCw4KCRYPCQMCAQIBFTAGAQwGAgEBiAkSqxuDMZAcBI8Tg0ADqk4 Received: from ppp118-209-136-183.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.136.183]) by ipmail07.adl2.internode.on.net with ESMTP; 05 Mar 2013 15:56:56 +1030 Message-ID: <51358219.9000802@nteczone.com> Date: Tue, 05 Mar 2013 16:26:49 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Robert Hansen , "clue@ietf.org" References: <5122892C.6000804@cisco.com> <512EFBB1.2020603@nteczone.com> <5134B70F.2040501@cisco.com> In-Reply-To: <5134B70F.2040501@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] draft-hansen-clue-sdp-interaction-00 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, 05 Mar 2013 05:27:19 -0000 Hello Robert, Please see my replies below. Regards, Christian On 5/03/2013 2:00 AM, Robert Hansen wrote: > > With regards to 4.2, you mention that middleboxes may want to alter the > > SDP without involving themselves in CLUE. Isn't this fought with > > problems if the middleboxes go and change SDP information related to > > Clue without understanding any constraints indicated by CLUE? > > I agree it can be problematic, but it's a problem we have to deal with > - middleboxes exist today that both monitor and alter SDP information, > and not all of them will understand CLUE. As such we need to make sure > that even if this leads to suboptimal behaviour it doesn't lead to an > invalid state of any sort. [CNG] If CLUE has references to the SDP and then the SDP gets changed doesn't that then lead to possible invalid state? i.e. an endpoint would receive a CLUE reference to SDP that is changed from what it originally intended? > > > Can you give examples of the reference CLUE->SDP? I've currently been > > thinking that as SDP will be used to establish media after the CLUE > > exchange that it would construct the SDP with a reference to the CLUE > > media capture or other construct. > > Assocating capture scenes (or individual captures) with specific > m-lines in the advertisment is one example, to say what m-lines are > controlled by the CLUE channel. Another example is in the configure, > if the receive streams/encodings are defined in SDP then the > information on what capture is assigned to each of those > streams/encodings in CLUE will be such a reference. [CNG] I can see that in a m-line you could reference a capture id, but I'm not sure how you would reference an m-line in a CLUE exchange. There's no m-line ID and given that the SDP exchange would occur after an Advertisement I'm not sure how this would be done? > > > Section 5: I support CLUE and SDP being independent. I'm abit confused > > regarding the "reference to SDP contents". I take it that we're not > > talking about using actual SDP in CLUE rather referring to the > > information indicated by SDP. > > Yes, as you say - I was trying to steer clear of specific syntax since > there's no settled answer on how the SDP will look, but rather than > duplicating SDP information in the CLUE channel I was talking about > making references to existing SDP information. > > Rob > > On 28/02/2013 06:39, Christian Groves wrote: >> Hello Rob, >> >> With regards to 4.2, you mention that middleboxes may want to alter the >> SDP without involving themselves in CLUE. Isn't this fought with >> problems if the middleboxes go and change SDP information related to >> Clue without understanding any constraints indicated by CLUE? >> >> Can you give examples of the reference CLUE->SDP? I've currently been >> thinking that as SDP will be used to establish media after the CLUE >> exchange that it would construct the SDP with a reference to the CLUE >> media capture or other construct. >> >> Section 5: I support CLUE and SDP being independent. I'm abit confused >> regarding the "reference to SDP contents". I take it that we're not >> talking about using actual SDP in CLUE rather referring to the >> information indicated by SDP. >> >> Regards, Christian >> >> >> On 19/02/2013 7:03 AM, Robert Hansen wrote: >>> Hi all, >>> >>> I've posted a new draft which will hopefully have a relatively short >>> lifespan on the topic of the interactions between CLUE signalling and >>> SDP - as we've discovered when we've tried to define things like call >>> flows a lot of the different aspects are dependant on each other, >>> making it hard to make a decision. I picked a couple of points that I >>> believe aren't so entangled. >>> >>> Some of these things in it are hopefully uncontroversial but haven't >>> always been documented yet, others are likely to provoke more >>> disagreement. >>> >>> There's no attempt in the draft at defining the SDP or CLUE messages, >>> the draft merely discusses what information is needed in each and how >>> they should interact. >>> >>> For -01 I hope to add some diagrams to better illustrate what's >>> going on. >>> >>> 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 Mark.Duckworth@polycom.com Tue Mar 5 08:07:24 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 DDE3D1F0D05 for ; Tue, 5 Mar 2013 08:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 hywXMwjawPba for ; Tue, 5 Mar 2013 08:07:24 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4404E21F8938 for ; Tue, 5 Mar 2013 08:07:24 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::5efe:10.236.0.200]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 5 Mar 2013 08:07:23 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 5 Mar 2013 08:07:22 -0800 Thread-Topic: [clue] Christer's initial comments on framework-09 Thread-Index: Ac4WbkTnE+TGM6znT+Srhw1siXylbQDTF+Kw Message-ID: <9C23AB934B394845A7B228239B6EAF41539FDE@CRPMBOXPRD01.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> <512FE233.8010104@nteczone.com> <7594FB04B1934943A5C02806D1A2204B10DEE8@ESESSMB209.ericsson.se> <51308DD6.4030309@alum.mit.edu> In-Reply-To: <51308DD6.4030309@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] Christer's initial comments on framework-09 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, 05 Mar 2013 16:07:25 -0000 I agree with Christian and Paul about Q1, and think the framework is okay a= s is. Section 6.2 says " The Capture Scene Entries in a Capture Scene are = different alternatives the provider is suggesting for representing the Capt= ure Scene." I agree with Christian and Paul about Q2, and think the framework is okay a= s is regarding the optional Simultaneous Transmission Set. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Friday, March 01, 2013 6:16 AM > To: clue@ietf.org > Subject: Re: [clue] Christer's initial comments on framework-09 >=20 > On 3/1/13 6:22 PM, Christer Holmberg wrote: > > Hi, > > > >> For Q1 I think the definition of CSE indicates that its an entire scen= e. > > > > Yes, the definition is probably ok. I am referring to text elsewhere in= the > draft. > > > >> With respect to Q2, I agree that's why we made the sending of the > simultaneous set optional. If the provider doesn't send the STS the consu= mer > assumes that all captures in the CSE can be provided simultaneously. > > > > EVEN if the provider sends STS, I think a provider MUST be able to prov= ide > a CSE. >=20 > I think this makes sense, but what to do if the simultaneous set conflict= s? >=20 > > In my opinion, the only use of STS is when one wants to simultaneously > provide captures belonging to different CSE/CS. But, as I indicated earli= er, in > my opinion is would be better to indicate Simultaneous CSE Set. >=20 > I disagree, because it may be feasible to provide *some* simultaneity but > not be able to provide two complete CSEs simultaneously. >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > > > > > > > > > On 28/02/2013 11:24 PM, Christer Holmberg wrote: > >> > >> Hi, > >> > >> A couple of initial comments: > >> > >> ------------------- > >> > >> Q1: Capture Scene and Capture Scene Entry editorial > >> > >> In a few places, there is text saying that "a Capture Scene includes > >> one or more Capture Scene Entries". I think that is a little > >> misleading, because it sounds like one uses one or more CSEs in order > >> to describe a CS. > >> > >> But, as each single CSE describes the whole scene, I think the text > >> should talk about CSEs providing alternatives for providing the CS. > >> > >> ------------------- > >> > >> Q2: Simultaneous Transmission Set > >> > >> We had a long discussion about this some time ago, and we never came > >> to a conclusion. I know there is another thread about STSs also, and > >> I will reply to that. > >> > >> But, I think that an endpoint shall always be able to simultaneously > >> provide all captures within a given CSE. So, there is no need to > >> explicitly advertise that the captures associated with a given CSE > >> can be provided simultaneously. > >> > >> ------------------- > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Mar 5 08:50: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 C935F21F862B for ; Tue, 5 Mar 2013 08:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[AWL=1.040, 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 1aIMESJ6VYOd for ; Tue, 5 Mar 2013 08:50:22 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 089A321F88E1 for ; Tue, 5 Mar 2013 08:50:21 -0800 (PST) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7o6l1l0041GhbT853sqMzC; Tue, 05 Mar 2013 16:50:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id 7sqM1l00E3ZTu2S3TsqMaQ; Tue, 05 Mar 2013 16:50:21 +0000 Message-ID: <5136224C.4020000@alum.mit.edu> Date: Wed, 06 Mar 2013 00:50:20 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Duckworth, Mark" References: <512A9240.3040800@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539E39@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF41539E39@CRPMBOXPRD01.polycom.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=1362502221; bh=TRtdqW7z3+EEy2jt8ZI0ZAM8rTBV/ArG2BEoDmv2yX8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MryMPBo2RZGre/Sl7EiKQqHuIOOxjcfr6vCOUZRrNqonbXWqQjDfsr+MvhyI/3TzN HPMH7hJKYJ5VHddV5sMkTYCFogDHUPKpV1nYaDMy8kYdyFG3SlIOtUyY7NHPvpg9dd FvQnd5f6olmuuJWLjbX/7hdsEsw8H3x/H2UcYPYrJ/0TXA4DEJFi+BgVsVN+UNx2AW nOCUbVJt1M4Aa0WF6QMapKLnq20W41VMapuNhfWIOnPYP4LwnKwpXox8qss2lRwFoY g644vYfrrwpdrUH61j9CeWVJ2m1jj0YZoQamNm7/rL7IWj8530ChJbANV4AZkEZOqE ff5/gVJed5xoQ== Cc: "clue@ietf.org" Subject: Re: [clue] New framework I-D posted 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, 05 Mar 2013 16:50:23 -0000 On 3/5/13 7:06 AM, Duckworth, Mark wrote: Trimming >> It was my understanding that we were not advocating doing anything that is >> contrary to the negotiated SDP. (E.g. using a codec not mentioned in the >> SDP.) But there are still plenty of changes that could potentially be made >> without violating the current SDP. E.g. selecting a new capture-encoding that >> uses an m-line that is already compatible. > > [Duckworth, Mark] I agree, Paul. If this is what the group wants, the framework document should clearly say CLUE devices follow all SDP O/A rules. Should we also refer to some specific RFCs? Since we are talking about SDP, we can at least reference 4566 and draft-ietf-mmusic-rfc4566bis. I don't think we need to mention any SDP extensions here unless we have reason to talk about them explicitly. >> Section 6.2.2: >> >> While it makes sense to outsource the detailed attributes here, IMO it is NOT >> ok to defer the definition of switching and composition to the data model. >> There should be a discussion of the concepts of that *somewhere*, and I >> can't think of a better place than the FW. For instance, the difference >> between site switching and segment switching, and the difference between >> switching and composition. (And of course that these have some differences >> between audio and video.) > > [Duckworth, Mark] I'm not sure exactly where to draw the line about which things go in which document. Site switch and segment switch description actually came from the use case document, we just repeated it in the framework. Are you suggesting we just keep in the framework some of the text about switching and composition that was already in the framework? And not move so much of it to another document? I don't think we define them very well at all. So we probably need some new text. Maybe somebody has a better idea, but ISTM that these are *concepts* that need to be explained. People may have a general notion from the names, but we should be more precise than that. Especially in the case of switching, this later becomes fundamental to the notions of dynamic and static mapping. Thanks, Paul From pkyzivat@alum.mit.edu Tue Mar 5 09:11:25 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 C30E621F890F for ; Tue, 5 Mar 2013 09:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.429 X-Spam-Level: X-Spam-Status: No, score=0.429 tagged_above=-999 required=5 tests=[AWL=0.866, 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 qJOxDX0YJ-w9 for ; Tue, 5 Mar 2013 09:11:20 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id B4DE721F8928 for ; Tue, 5 Mar 2013 09:11:19 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7nde1l00G1wpRvQ53tBKjl; Tue, 05 Mar 2013 17:11:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id 7tBJ1l00s3ZTu2S3etBKoo; Tue, 05 Mar 2013 17:11:19 +0000 Message-ID: <51362736.7070401@alum.mit.edu> Date: Wed, 06 Mar 2013 01:11:18 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512EF700.2080207@nteczone.com> <9C23AB934B394845A7B228239B6EAF41539E72@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF41539E72@CRPMBOXPRD01.polycom.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=1362503479; bh=rv3l8pEIdQ0L/Wxa4ojCTOl2SpCVNpO1Z4L3XzQvE+k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Exw6CMjrVeVHlc5p/Xnl+tdSw0OYhuTVGufVnS7D/63B4STN4+aU8ankwnPh4hJ6Y Wf5JSVJYp8TNiBNIla20fvjsPAvqMpt8grWLW4z6t8JmCeIuQT4EEW5RSsAMbKXpDb yOyE7z24J1hqR9KPnTjomYs1lAeF5jWbPPBhee/LdgHYxvWMtRTejFuKwvPktSLWHi /ZiZOnRh74dAjryMLJxZ4NaK/S9F7dLHR2b5I42nCr54QD80qysbcqiq4jpNiLKIpf 1pDU0c7YZrs2yeVC37xPYrJz92VTT5KYfm2kWOKfXlx4S6NDEDP2b1U0xF1PhPh0/D bi93+IqFhmDRA== Subject: Re: [clue] New framework I-D posted 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, 05 Mar 2013 17:11:25 -0000 On 3/5/13 9:11 AM, Duckworth, Mark wrote: >> General: Text capture: According to our definitions CLUE support Text >> captures. i.e. Media indicates the possibility of timed text, A media capture >> indicates that its the source of "media". We also talk about streams being >> RTP. Sect 6.3 also talks about captures of a particular type (audio, video, >> text). If we are supporting it then we may be a "Text Capture" (TC). This may >> be an issue for Orlando. > > [Duckworth, Mark] I agree we should include text, and possibly other types of media but I don't have any specific examples. Maybe this issue is a more for the data model, to make sure it doesn't exclude other media types that go over RTP? I think there may be some subtle issues that show up when considering real-time-text captures. Specifically, there may not be dedicated devices for rendering this text. Should it be rendered on top of video displays? Should the spatial coordinates indicate where it ought to be rendered, or what? Also, how does switching work with these? ISTM that we should defer this, or have some people work on it independently in parallel with other work, to avoid getting distracted. But at least we should set up the data model to allow additional types of captures, beyond audio and video. >> Section 4 Figure: In the signalling document it shows ACKs to the >> Advertisement and Configure messages. Do we want to show those in the >> framework or at least say for brevity acknowledgements aren't shown? > > [Duckworth, Mark] I think after we get a somewhat stable signaling document we should make sure all the documents are consistent. I don't think we need to mention ACK in the FW at all. It is signaling-related detail. >> Section 5: With respect to the coordinate system and the origin. We say that >> the location of the origin is up to the provider's choosing. Would it be >> beneficial to suggest a location for it? >> >> Section 6.1.1: It says that capture attributes provide "static" >> information? What is meant by static here? Is it for the life of the CLUE >> association. Static until the next Advertisement is sent? I suggest deleting it. > > [Duckworth, Mark] I think anything can change from one advertisement to the next, so I agree we should delete the word "static". > >> Section 6.1.1: I'd prefer not to outsource the definitions of these attributes >> to the data model. Part of the framework is to understand what this >> information is used for. > > [Duckworth, Mark] Seems like we need more discussion on where to draw the line between what goes in framework and what goes in the data model. > >> Section 6.1.1: Area of capture: for consistency we should probably use >> "bottom camera left", "top camera right", etc... > > [Duckworth, Mark] I agree > >> Section 6.2 Pg.19 Para.4: I'm not sure this reflects the discussions we've had >> on the list. It basically says says that the consumer can do what ever it likes. I >> thought there was some agreement that the consumer SHOULD chose a CSE >> and that these were alternate representation of the entire scene (at least >> according to the scene definition). Section 6.3 mentions choosing only one >> CSE. > > [Duckworth, Mark] Yes, the Consumer can choose whatever it wants, subject to constraints of the advertisement. Section 6.3 says "... the Consumer should choose one Capture Scene Entry for each media type, but may choose individual Captures based on the Simultaneous Transmission Sets." I think the framework is saying what we agreed on the list. But maybe not clearly enough? Do you have a specific suggestion? > >> Section 6.2.1: Like above I think its worth having some description in the >> framework document. You should need to look into two documents to get >> the gist of what CLUE is doing. >> >> Section 6.2.1 Area of scene: If this is specified I take it that it must be greater >> than or equal to the outer extents of the individual captures? If it was smaller >> what would it mean? > > [Duckworth, Mark] Yes, I think it should be greater than or equal to the outer extents of the individual captures. Some time ago I mentioned that the Area of Scene needs to be three dimensional (Volume of Scene?). Otherwise it doesn't reasonable accommodate arrangements of captures that not planar. >> Section 6.2.2: Should the scene switch policy be at a Capture scene level? For >> example if we allow the consumer to cherry pick captures from different >> CSEs what happens? Are the capture only related to a CSE switched together >> or all captures related to the scene switched? > > [Duckworth, Mark] Good question. Related to Paul's question about picking different CSEs for different media types, which could have different values for the scene-switch-policy. This relates to my question about providing a thorough description of switching in the FW. That should include how switched video captures relate to switched audio captures (and switched real-time-text captures). Thanks, Paul From pkyzivat@alum.mit.edu Tue Mar 5 10:01:34 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 4AEA721F8617 for ; Tue, 5 Mar 2013 10:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.606 X-Spam-Level: X-Spam-Status: No, score=0.606 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_15=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 yT8cKtczyaKL for ; Tue, 5 Mar 2013 10:01:33 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0451621F84DF for ; Tue, 5 Mar 2013 10:01:32 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id 7q5F1l0050ldTLk53u1YZG; Tue, 05 Mar 2013 18:01:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 7u1Y1l00H3ZTu2S3Qu1Yjl; Tue, 05 Mar 2013 18:01:32 +0000 Message-ID: <513632FC.5000602@alum.mit.edu> Date: Wed, 06 Mar 2013 02:01:32 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <5122892C.6000804@cisco.com> <512EFBB1.2020603@nteczone.com> <5134B70F.2040501@cisco.com> <51358219.9000802@nteczone.com> In-Reply-To: <51358219.9000802@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=1362506492; bh=xUvvu472PpHektHVM1bCGNTDtm9dqMcSgMyY3mejmaQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=X+rbz7YAn41CAf2AttZJVdrwsw8Ia4EHsRrErpwD4pNPpAJf68peFYkaZDGlOaOkL 6Vf0St8dUPQw9Bbe+nn1uOWSvY/UMmZItpcXT6V6P0GTwZJox2xmRn6SykANcV9psb qkLfbmmxvbQkMBjBqLPG4mqA9H5etyoCdi+i9WnTsVYhPyKj4bdIUSY8Q9aZCKcvgj Zey/hyrmUeA+jU66pT8SiPfHmsWr++jQcLGYXR1z33yFKRXGveaAjUkQlAk8qq9rTP BeNXLO5uFxAnmEHEHtZeSw1c2+4yfcTRrIkjRS5z48YCmQabAodfHAuEUSds/g8z8r kzc5OzA2dgikg== Subject: Re: [clue] draft-hansen-clue-sdp-interaction-00 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, 05 Mar 2013 18:01:34 -0000 On 3/5/13 1:26 PM, Christian Groves wrote: > Hello Robert, > > Please see my replies below. > > Regards, Christian > > On 5/03/2013 2:00 AM, Robert Hansen wrote: >> > With regards to 4.2, you mention that middleboxes may want to alter the >> > SDP without involving themselves in CLUE. Isn't this fought with >> > problems if the middleboxes go and change SDP information related to >> > Clue without understanding any constraints indicated by CLUE? >> >> I agree it can be problematic, but it's a problem we have to deal with >> - middleboxes exist today that both monitor and alter SDP information, >> and not all of them will understand CLUE. As such we need to make sure >> that even if this leads to suboptimal behaviour it doesn't lead to an >> invalid state of any sort. > [CNG] If CLUE has references to the SDP and then the SDP gets changed > doesn't that then lead to possible invalid state? i.e. an endpoint would > receive a CLUE reference to SDP that is changed from what it originally > intended? Of course this depends on what sorts of changes the middleboxes are making. There are no "rules" for this, so we can only work with known observed behavior. If the middlebox does something really awful then things are going to break. Some things we know are relatively common are: - admission control - looking at what the SDP needs and then accepting or rejecting the call. Not much we can do about this. - limit media usage - perhaps block video at certain times. This will break TP. But as long as the blocking is done by zeroing out the ports in the m-lines we can at least work with what is allowed. If blocking is done by removing m-lines then it may make a terrible mess. But I don't think anyone does that. - codec policing - remove "undesirable" codecs from offers and answers. We should be able to work with this, but depending on details it may make a mess. - bandwidth limitation - adjust offers and answers to put reduced maxima on bandwidth. To some extent we can probably work with this. - bandwidth policing - monitor media and block it when it exceeds the negotiated bandwidth. This should not cause us any trouble. But this can get complicated in some of the bundling proposals if the middle box doesn't understand the bundling. We need to consider that as part of the bundling proposals if we use them. - gating media flows - block media from flowing except that which complies with observed O/A exchanges. This should be ok. - policing SDP usage/syntax in general. This could cause great trouble if the middle box doesn't understand what we are using. But I don't think this is very common. If we want to *refer* to the SDP from the CLUE signaling, then I expect it will be via a=label attributes in the SDP. We will be OK as long as middle boxes don't drop those labels. In general I think we will be OK. >> > Can you give examples of the reference CLUE->SDP? I've currently been >> > thinking that as SDP will be used to establish media after the CLUE >> > exchange that it would construct the SDP with a reference to the CLUE >> > media capture or other construct. >> >> Assocating capture scenes (or individual captures) with specific >> m-lines in the advertisment is one example, to say what m-lines are >> controlled by the CLUE channel. Another example is in the configure, >> if the receive streams/encodings are defined in SDP then the >> information on what capture is assigned to each of those >> streams/encodings in CLUE will be such a reference. > [CNG] I can see that in a m-line you could reference a capture id, but > I'm not sure how you would reference an m-line in a CLUE exchange. > There's no m-line ID and given that the SDP exchange would occur after > an Advertisement I'm not sure how this would be done? a=label is intended for application level reference to the SDP. If the SDP is to be updated *after* the CLUE exchange, then the reference may not be satisfied until it is. But in some cases it will make sense to reference SDP that is already in effect. Thanks, Paul From christer.holmberg@ericsson.com Wed Mar 6 01:41:51 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 AB2A721F8A06 for ; Wed, 6 Mar 2013 01:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 hA3TyJMwk2vb for ; Wed, 6 Mar 2013 01:41:51 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE8521F874F for ; Wed, 6 Mar 2013 01:41:49 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-3e-51370f5c431a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A1.67.32353.C5F07315; Wed, 6 Mar 2013 10:41:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 10:41:46 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] Christer's initial comments on framework-09 Thread-Index: Ac4VroADjRD7KAXuTk65+jHWtYvPhAAUOg6AABjxL+AAAKI9AADTW08AACbEJ3A= Date: Wed, 6 Mar 2013 09:41:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B113AF2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> <512FE233.8010104@nteczone.com> <7594FB04B1934943A5C02806D1A2204B10DEE8@ESESSMB209.ericsson.se> <51308DD6.4030309@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539FDE@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF41539FDE@CRPMBOXPRD01.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvjW4sv3mgwZofjBb7T11mtlh35Cmz A5PHkiU/mTxePFAKYIrisklJzcksSy3St0vgyrh37CBLwSSFitl/7jI1MB6T7GLk5JAQMJHY 9/YMK4QtJnHh3nq2LkYuDiGBQ4wSuzZuYIRwFjFKvHp2Ccjh4GATsJDo/qcN0iAiECqxeuYm FhBbWMBe4sWEOUwQcQeJebNWMULYfhLfPoAM5eRgEVCRaNn+BczmFfCWmNN1hQli/lQmiRPT l4I1cwI1LDlwmR3EZgS66PupNWBxZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/UB8oSlydvhyq Xkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY2XMTM3PSy803 MQJj4eCW3wY7GDfdFzvEKM3BoiTOG+56IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo7Zj RMXLSYo3mjv1MtXMP/6wn/WhZ6/gjOkhfPvvdlySfZbq2b3PZxFz2Lzqqco+7PGnbDcerJUS f6OtqPmjwur2/V6do+unfuBZNkEwJODnObWAgvm+m10rP6nv/PCUcceSa6E13L91bjPNuWXd pjI3s+3Omo3nmix3vLq0NjNloUHVLumlTkosxRmJhlrMRcWJAFWtxMdTAgAA Subject: Re: [clue] Christer's initial comments on framework-09 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, 06 Mar 2013 09:41:51 -0000 Hi, >I agree with Christian and Paul about Q1, and think the framework is okay = as is. Section 6.2 says " The Capture Scene Entries in a Capture Scene are= different alternatives the provider is suggesting for representing the Cap= ture Scene." > >I agree with Christian and Paul about Q2, and think the framework is okay = as is regarding the optional Simultaneous Transmission Set. I am ok with providing both CSEs and individual captures.=20 But, we need to make it clear that, if a provider in the same set entry pro= vides both a CSE and a capture, and the capture is also part of the CSE, it= provides two "instances" (we can come up with better wording) of the same = capture. Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Friday, March 01, 2013 6:16 AM > To: clue@ietf.org > Subject: Re: [clue] Christer's initial comments on framework-09 >=20 > On 3/1/13 6:22 PM, Christer Holmberg wrote: > > Hi, > > > >> For Q1 I think the definition of CSE indicates that its an entire scen= e. > > > > Yes, the definition is probably ok. I am referring to text elsewhere=20 > > in the > draft. > > > >> With respect to Q2, I agree that's why we made the sending of the > simultaneous set optional. If the provider doesn't send the STS the=20 > consumer assumes that all captures in the CSE can be provided simultaneou= sly. > > > > EVEN if the provider sends STS, I think a provider MUST be able to=20 > > provide > a CSE. >=20 > I think this makes sense, but what to do if the simultaneous set conflict= s? >=20 > > In my opinion, the only use of STS is when one wants to=20 > > simultaneously > provide captures belonging to different CSE/CS. But, as I indicated=20 > earlier, in my opinion is would be better to indicate Simultaneous CSE Se= t. >=20 > I disagree, because it may be feasible to provide *some* simultaneity=20 > but not be able to provide two complete CSEs simultaneously. >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > > > > > > > > > On 28/02/2013 11:24 PM, Christer Holmberg wrote: > >> > >> Hi, > >> > >> A couple of initial comments: > >> > >> ------------------- > >> > >> Q1: Capture Scene and Capture Scene Entry editorial > >> > >> In a few places, there is text saying that "a Capture Scene=20 > >> includes one or more Capture Scene Entries". I think that is a=20 > >> little misleading, because it sounds like one uses one or more CSEs=20 > >> in order to describe a CS. > >> > >> But, as each single CSE describes the whole scene, I think the text=20 > >> should talk about CSEs providing alternatives for providing the CS. > >> > >> ------------------- > >> > >> Q2: Simultaneous Transmission Set > >> > >> We had a long discussion about this some time ago, and we never=20 > >> came to a conclusion. I know there is another thread about STSs=20 > >> also, and I will reply to that. > >> > >> But, I think that an endpoint shall always be able to=20 > >> simultaneously provide all captures within a given CSE. So, there=20 > >> is no need to explicitly advertise that the captures associated=20 > >> with a given CSE can be provided simultaneously. > >> > >> ------------------- > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Mar 6 06:21: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 6389F21F8934 for ; Wed, 6 Mar 2013 06:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 tUFAY4xb6s6r for ; Wed, 6 Mar 2013 06:21:02 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id ADB5C21F8922 for ; Wed, 6 Mar 2013 06:21:02 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([::1]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 6 Mar 2013 06:21:02 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 6 Mar 2013 06:20:59 -0800 Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiOlViAgACHS4CAAYd9AIAB4kNigAG+kwCAAK4VAIAAUHYggAN8bsA= Message-ID: <9C23AB934B394845A7B228239B6EAF416F09A1@CRPMBOXPRD01.polycom.com> References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>,<51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> <51339B72.6070203@unina.it> <51342D7A.4020109@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1106B1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1106B1@ESESSMB209.ericsson.se> 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] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:21:03 -0000 Christer wrote: > I agree. If you reference a CS, and some capture is used in multiple > associated CSEs, it means that you are able to provide multiple "instance= s" of > the capture - one for each CSE where it is used. This does not make sense to me. Simultaneous Transmission Sets should not = be used to indicate how many "instances" (I think you mean Capture Encoding= s) of a Media Capture a Provider can provide. That information is in the E= ncoding Group associated with the Media Capture. I think if a Media Capture appears more than once in a Simultaneous Transmi= ssion Set, directly or indirectly, it means the same thing as if it appeare= d only once. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Monday, March 04, 2013 4:05 AM > To: Paul Kyzivat; Roberta Presta > Cc: clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets >=20 > Hi, >=20 > >>>>> My proposal is, instead of listing all the captures, using capture > >>>>> scene identifiers and capture scene entry identifiers, and > >>>>> building simultaneous sets as: > >>>>> - CSB, CSC, CSE3_A, CSE1_A > >>>>> - CSB, CSC, CSE3_A, CSE2_A > >>>> So, taking your example, does CSB indicate that I can provide ANY > >>>> CSE associated with CSB, or that I can provide ALL CSEs associated w= ith > CSB? > >> > >> Listing a capture scene identifier like CSB in a simultaneous set > >> should mean the provider is able to send simultaneously all the > >> captures within the capture scene entries associated with that capture > scene. > >> Or, at least, that was what I had in mind. > >> It is in line with the current definition of the simultaneous sets > >> (Simultaneous transmission sets are expressed as sets of the Media > >> Captures that could physically be transmitted at the same time). > >> Regards, > > > > Ah, ok - that makes sense. > > > > So referencing a CSE means all the captures in it, and referencing a > > CS means all the CSEs in it. With that interpretation, then referencing= a CS > could implicitly reference a single capture more than once. So a corollar= y is > that referencing a single capture more than once is not an error. >=20 > I agree. If you reference a CS, and some capture is used in multiple > associated CSEs, it means that you are able to provide multiple "instance= s" of > the capture - one for each CSE where it is used. >=20 > The same thing would apply if you reference a CSE, and a capture within i= t: it > means you are able to provide two "instances" of the capture. >=20 > So, while I can't think of any use-case at the moment, I agree that we sh= ould > not consider it an error case. But, we need to make sure it's clearly > documented :) >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Mar 6 06:28:45 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 474B421F8ABA for ; Wed, 6 Mar 2013 06:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.132 X-Spam-Level: X-Spam-Status: No, score=-0.132 tagged_above=-999 required=5 tests=[AWL=0.305, 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 8W+otR2H+hfZ for ; Wed, 6 Mar 2013 06:28:44 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id CDD6321F8AB4 for ; Wed, 6 Mar 2013 06:28:43 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id 8BRS1l0081c6gX851EUjqA; Wed, 06 Mar 2013 14:28:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 8EUi1l01A3ZTu2S3jEUjop; Wed, 06 Mar 2013 14:28:43 +0000 Message-ID: <5137529A.5060402@alum.mit.edu> Date: Wed, 06 Mar 2013 22:28:42 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> <512FE233.8010104@nteczone.com> <7594FB04B1934943A5C02806D1A2204B10DEE8@ESESSMB209.ericsson.se> <51308DD6.4030309@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539FDE@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B113AF2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B113AF2@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=1362580123; bh=Omt19UnELf/u0W+fxeh5QWPAl8iZAtNlbGcmVccoLbI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SA1WwkVdp6vkaD7q5Mp+xTlL6YPGsbe5p/A6rS1AqV+jvlr67uUbA+7t2K9U1wl8v gfCKYMfunmrs9uLnuBD6bpcwHov3JzbKLjrNQmjZ7wBaiq++Q+G/IB9mhI+dMSZhOK ZcO3U/KO5A6khgn7qI4euEcjudPFEhp1LQjnXSTkS0mzrg2K5PBBNCidpgaJXskvTS IsuLqzOWsnKtSc7GKou9OmSy4l8nVfLSkBP757KLJFWqwhC8F7cgYinfS4ALz/Z9KS uqcz4LjEy1iVihcCrTKKlaeIWbIG6nLlSVw0fs4sVgOp2ZpY+ALF/NJuwya0jKS8gu qRfTMs/Lv04jg== Subject: Re: [clue] Christer's initial comments on framework-09 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, 06 Mar 2013 14:28:45 -0000 On 3/6/13 5:41 PM, Christer Holmberg wrote: > Hi, > >> I agree with Christian and Paul about Q1, and think the framework is okay as is. Section 6.2 says " The Capture Scene Entries in a Capture Scene are different alternatives the provider is suggesting for representing the Capture Scene." >> >> I agree with Christian and Paul about Q2, and think the framework is okay as is regarding the optional Simultaneous Transmission Set. > > I am ok with providing both CSEs and individual captures. > > But, we need to make it clear that, if a provider in the same set entry provides both a CSE and a capture, and the capture is also part of the CSE, it provides two "instances" (we can come up with better wording) of the same capture. Why? I don't think that this necessarily should mean that. Providing the same capture multiple times is simulcast, and I thought we were handling that separately via the MaxCaptureEncodings element of the data model. Thanks, Paul > Regards, > > Christer > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Friday, March 01, 2013 6:16 AM >> To: clue@ietf.org >> Subject: Re: [clue] Christer's initial comments on framework-09 >> >> On 3/1/13 6:22 PM, Christer Holmberg wrote: >>> Hi, >>> >>>> For Q1 I think the definition of CSE indicates that its an entire scene. >>> >>> Yes, the definition is probably ok. I am referring to text elsewhere >>> in the >> draft. >>> >>>> With respect to Q2, I agree that's why we made the sending of the >> simultaneous set optional. If the provider doesn't send the STS the >> consumer assumes that all captures in the CSE can be provided simultaneously. >>> >>> EVEN if the provider sends STS, I think a provider MUST be able to >>> provide >> a CSE. >> >> I think this makes sense, but what to do if the simultaneous set conflicts? >> >>> In my opinion, the only use of STS is when one wants to >>> simultaneously >> provide captures belonging to different CSE/CS. But, as I indicated >> earlier, in my opinion is would be better to indicate Simultaneous CSE Set. >> >> I disagree, because it may be feasible to provide *some* simultaneity >> but not be able to provide two complete CSEs simultaneously. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> On 28/02/2013 11:24 PM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>> A couple of initial comments: >>>> >>>> ------------------- >>>> >>>> Q1: Capture Scene and Capture Scene Entry editorial >>>> >>>> In a few places, there is text saying that "a Capture Scene >>>> includes one or more Capture Scene Entries". I think that is a >>>> little misleading, because it sounds like one uses one or more CSEs >>>> in order to describe a CS. >>>> >>>> But, as each single CSE describes the whole scene, I think the text >>>> should talk about CSEs providing alternatives for providing the CS. >>>> >>>> ------------------- >>>> >>>> Q2: Simultaneous Transmission Set >>>> >>>> We had a long discussion about this some time ago, and we never >>>> came to a conclusion. I know there is another thread about STSs >>>> also, and I will reply to that. >>>> >>>> But, I think that an endpoint shall always be able to >>>> simultaneously provide all captures within a given CSE. So, there >>>> is no need to explicitly advertise that the captures associated >>>> with a given CSE can be provided simultaneously. >>>> >>>> ------------------- >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Wed Mar 6 06:32: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 85C2A21F8AC2 for ; Wed, 6 Mar 2013 06:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 AGYzQ0b4XL0u for ; Wed, 6 Mar 2013 06:32:41 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id D410721F8AC1 for ; Wed, 6 Mar 2013 06:32:41 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([::1]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 6 Mar 2013 06:31:24 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 6 Mar 2013 06:32:39 -0800 Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: Ac4VGq9cEidN6xZqTEym6pnroVfLYQFW8S+w Message-ID: <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> References: <512E54AD.9090707@unina.it> In-Reply-To: <512E54AD.9090707@unina.it> 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] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:32:42 -0000 I will try to summarize what I think the conclusions are from this thread. Point 1 - we generally agree simultaneity restrictions are not just about p= hysical constraints, there are other reasons. Point 2 - we should remove the bit about "may not make sense to do so". Point 3 - we generally agree it would be good to allow expressing Simultane= ous Transmission Sets as lists of Capture Sets, Capture Set Entries, as wel= l as Media Captures that the Provider can provide simultaneously. Point 4 - we generally agree (again) we do not want to define other ways of= expressing Simultaneous Transmission Sets, such as by mutual exclusion or = with logical operators. Regards, Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roberta Presta > Sent: Wednesday, February 27, 2013 1:47 PM > To: clue@ietf.org > Subject: [clue] comments to framework 09 - simultaneous sets >=20 > Hi all, >=20 > sorry for boring you always with the same things :) >=20 > When I read Section 6.3 "Simultaneous Transmission Set Constraint", I > noticed a couple of things: >=20 > 1) the only motivation that has been provided to justify the definition o= f > simultaneous sets is the fact that captures generated from the same devic= e > cannot be sent simultaneously. However, there can be other motivations > behind the need of expressing simultaneity constraints (leaving resource > constraints handled by encoding groups and other stuff such as max- > encoding- and so on). > Citing Andy Pepperel in > http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, > simultaneous sets can be used by MCUs that might not want to be obliged t= o > provide some capture simultaneously, in order to avoid overloading. > I think that these other motivations should be explicitely mentioned in t= he > framework document to explain that simultaneity limitations may not be du= e > only to physical constraints. >=20 > 2) Copying from the document: "Simultaneous transmission sets are > expressed as sets of the Media Captures that could physically be transmit= ted > at the same time (though it may not make sense to do so). " > Does it mean that even if there is a large set of captures able to be sen= t > simultaneously, it may not make sense, from the consumer's perspective, t= o > receive them all together? Maybe rewording is needed here. >=20 > 3) Again, on the design (and definition) of the simultaneous sets. >=20 > Simultaneous sets, as defined in the framework, are *all* the groups of > *captures* that can be sent together. > The consumer presumably has to check if the set of captures he wants is f= ully > *included* in almost one of the listed ones. > If not, he has to re-structure the configure to fit simultaneity constrai= nts > expressed by the provider. > (Is that the expected behavior of the consumer?) >=20 > I was thinking that each set can be expressed also in terms of capture sc= ene > entries, or capture scene as a whole, for example: > 1) CSE1, CSE2, CS3, VC1, CS5 > 2) CSE1, CSE4, CS3, VC1, CS5 > .... > Where CSE* identifies a capture scene entry, and CS* identifies a capture > scene. > That can allow to make simultaneous sets more synthetic by exploiting the > capture aggregates the framework envisions. It can be particularly useful= to > MCUs that want to offer just subsets of the complete list of capture scen= es > they receive from multiple contributors. >=20 >=20 > 4) Some further reasoning. >=20 > In some cases it can be more efficient to express only mutual exclusion > constraints. > We could discuss about envisioning a section of information named > "simultaneity constraints" that can include a list of simultaneous sets a= nd a > list of mutual exclusion conditions to be checked on the consumer's side. > For example, if a media provider offers many captures, and has only 4 mut= ual > exclusion conditions, instead of listing all the possible simultaneous se= ts, he > can just provide the 4 mutual exclusion conditions to the consumer. >=20 > Another alternative is also Christer Holmberg's proposal in > http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, where > simultaneity constraints are logical conditions that the consumer has to = verify > before issuing a configure to the provider. > The example was: >=20 > "(CSE-X AND CSE-Y) OR CSE-Z. >=20 > This means that the provider can provide CSE-X and CSE Y (and all capture= s > associated with CSE-X and CSE-Y) simultaneously, or that the provider can > provide CSE-Z (and all captures associated with CSE-Z)." >=20 > Do you think we should stuck on the framework solution or also consider t= he > aforementioned alternatives? > I promise I stop thinking about it! >=20 > RP >=20 > -- > Roberta Presta, Ph.D. Student > Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione > (DIETI) Universita' degli Studi di Napoli "Federico II" > Via Claudio 21 -- 80125 Napoli (Italy) > Phone: +390817683821 - Fax: +390817683816 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Mar 6 06:46:54 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 6397D21F8AEA for ; Wed, 6 Mar 2013 06:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 sEiWBXhLhWkb for ; Wed, 6 Mar 2013 06:46:53 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 265F321F8BE9 for ; Wed, 6 Mar 2013 06:46:52 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-f3-513756db6052 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6C.E2.10459.BD657315; Wed, 6 Mar 2013 15:46:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 15:46:51 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Christer's initial comments on framework-09 Thread-Index: Ac4VroADjRD7KAXuTk65+jHWtYvPhAAUOg6AABjxL+AAAKI9AADTW08AACbEJ3AACBRNAAACswDA Date: Wed, 6 Mar 2013 14:46:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B113E6F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> <512FE233.8010104@nteczone.com> <7594FB04B1934943A5C02806D1A2204B10DEE8@ESESSMB209.ericsson.se> <51308DD6.4030309@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539FDE@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B113AF2@ESESSMB209.ericsson.se> <5137529A.5060402@alum.mit.edu> In-Reply-To: <5137529A.5060402@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+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje7tMPNAg/YpChb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXROf8Bc8EZlYruf/cYGxg/ynYxcnJICJhI TNi3jBXCFpO4cG89WxcjF4eQwCFGiU/757OBJIQEFjFKzD/G3cXIwcEmYCHR/U8bJCwi4Cmx 4+MUZhBbWMBe4sWEOUwQcQeJebNWMYKUiwhESbzeZwUSZhFQkdi74hZYCa+At8SifS+YIVb9 ZJJYNmUr2BxOAR2JNb/2ghUxAt3z/dQaMJtZQFzi1pP5TBB3Ckgs2XOeGcIWlXj5+B/U/YoS V6cvh6rXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkb23MTM nPRyw02MwEg4uOW37g7GU+dEDjFKc7AoifOGuV4IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cDIoriwsP6W6KXZzyZPjd4vo8X4kWVL6Csb1t2LJpya/F9W2c6AyT7s1d9O1jNJl9LmLC/0 OpfcGu6Sm8ipmLJTj/+SoONd3dkFytNOXFxrxfpmbUpZ58SwaQ3/E8Ic3YOCQ9UOugT7nZXj 8efI7zv3QX+WZJxNqqLkcd/E5rKJcybNKncz9lViKc5INNRiLipOBABio6MIUgIAAA== Subject: Re: [clue] Christer's initial comments on framework-09 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, 06 Mar 2013 14:46:54 -0000 Hi, >>> I agree with Christian and Paul about Q1, and think the framework is ok= ay as is. Section 6.2 says " The Capture Scene Entries in a Capture Scene = are different alternatives the provider is suggesting for representing the = Capture Scene." >>> >>> I agree with Christian and Paul about Q2, and think the framework is ok= ay as is regarding the optional Simultaneous Transmission Set. >> >> I am ok with providing both CSEs and individual captures. >> >> But, we need to make it clear that, if a provider in the same set entry = provides both a CSE and a capture, and the capture is also part of the CSE,= it provides two "instances" (we can come up with better wording) of the sa= me capture. > > Why? I don't think that this necessarily should mean that. > Providing the same capture multiple times is simulcast, and I thought we = were handling that separately via the MaxCaptureEncodings element of the da= ta model. So what does it mean? "Unspecified"? Regards, Christer >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 >> Of Paul Kyzivat >> Sent: Friday, March 01, 2013 6:16 AM >> To: clue@ietf.org >> Subject: Re: [clue] Christer's initial comments on framework-09 >> >> On 3/1/13 6:22 PM, Christer Holmberg wrote: >>> Hi, >>> >>>> For Q1 I think the definition of CSE indicates that its an entire scen= e. >>> >>> Yes, the definition is probably ok. I am referring to text elsewhere=20 >>> in the >> draft. >>> >>>> With respect to Q2, I agree that's why we made the sending of the >> simultaneous set optional. If the provider doesn't send the STS the=20 >> consumer assumes that all captures in the CSE can be provided simultaneo= usly. >>> >>> EVEN if the provider sends STS, I think a provider MUST be able to=20 >>> provide >> a CSE. >> >> I think this makes sense, but what to do if the simultaneous set conflic= ts? >> >>> In my opinion, the only use of STS is when one wants to=20 >>> simultaneously >> provide captures belonging to different CSE/CS. But, as I indicated=20 >> earlier, in my opinion is would be better to indicate Simultaneous CSE S= et. >> >> I disagree, because it may be feasible to provide *some* simultaneity=20 >> but not be able to provide two complete CSEs simultaneously. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> On 28/02/2013 11:24 PM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>> A couple of initial comments: >>>> >>>> ------------------- >>>> >>>> Q1: Capture Scene and Capture Scene Entry editorial >>>> >>>> In a few places, there is text saying that "a Capture Scene=20 >>>> includes one or more Capture Scene Entries". I think that is a=20 >>>> little misleading, because it sounds like one uses one or more CSEs=20 >>>> in order to describe a CS. >>>> >>>> But, as each single CSE describes the whole scene, I think the text=20 >>>> should talk about CSEs providing alternatives for providing the CS. >>>> >>>> ------------------- >>>> >>>> Q2: Simultaneous Transmission Set >>>> >>>> We had a long discussion about this some time ago, and we never=20 >>>> came to a conclusion. I know there is another thread about STSs=20 >>>> also, and I will reply to that. >>>> >>>> But, I think that an endpoint shall always be able to=20 >>>> simultaneously provide all captures within a given CSE. So, there=20 >>>> is no need to explicitly advertise that the captures associated=20 >>>> with a given CSE can be provided simultaneously. >>>> >>>> ------------------- >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Mar 6 06:47: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 AE59121F8C04 for ; Wed, 6 Mar 2013 06:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 gZBD6Q0igsiE for ; Wed, 6 Mar 2013 06:47:56 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9B61221F8BF6 for ; Wed, 6 Mar 2013 06:47:55 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-01-5137571a789a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C2.0C.32353.A1757315; Wed, 6 Mar 2013 15:47:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 15:47:53 +0100 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiOlViAgACHS4CAAYd9AIAB4kNigAG+kwCAAK4VAIAAUHYggAN8bsCAAAjUkA== Date: Wed, 6 Mar 2013 14:47:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B113E83@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> <512F47E1.9090600@unina.it>,<51309048.6010507@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B10F20D@ESESSMB209.ericsson.se> <51339B72.6070203@unina.it> <51342D7A.4020109@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1106B1@ESESSMB209.ericsson.se> <9C23AB934B394845A7B228239B6EAF416F09A1@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF416F09A1@CRPMBOXPRD01.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvja5UuHmgwYbFuhb7T11mtlh35Cmz A5PHkiU/mTxePFAKYIrisklJzcksSy3St0vgyti0bhJbwRfJivPvTjI3MN4R6WLk5JAQMJFo W97MAmGLSVy4t56ti5GLQ0jgEKPE3R1zmSGcRYwSh+6eYe1i5OBgE7CQ6P6nDdIgIhAqsXrm JrBmYQEHiZZfU1gh4o4Sq1bNY4GwsyQOrzrHAtLKIqAiMW+9JEiYV8BbouVHNxPE+E5miVdL ZrCDJDgF/CSe31/HDGIzAh30/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4StKHF1 +nKoeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9NzMxJ LzffxAiMhINbfhvsYNx0X+wQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jN4ivpqnj1bvUYqWniLS3RWidajU0H9z0LLLX5U8otvtPq7XWxsts0w56/T9bX5Zj/41Pwo9 bZtofNfmTfynCy1ubqFzud2u7nydH/Vg2m4d9Y3N1yIqOfc/av0Rpr7q3TNnRctF8vI75vt2 mZ/eFO2Yf+ToxHyrzNNrX9sdWf9P5OHS5g0OG5VYijMSDbWYi4oTAQAw5tpSAgAA Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 14:47:56 -0000 Hi, >> I agree. If you reference a CS, and some capture is used in multiple=20 >> associated CSEs, it means that you are able to provide multiple=20 >> "instances" of the capture - one for each CSE where it is used. > > This does not make sense to me. Simultaneous Transmission Sets should no= t be used to indicate how=20 > many "instances" (I think you mean Capture Encodings) of a Media Capture = a Provider can provide. That information is in the Encoding Group associat= ed with the Media Capture. > > I think if a Media Capture appears more than once in a Simultaneous Trans= mission Set, directly or indirectly, it means the same thing as if it appea= red only once. I can live with that, but it STILL needs to be clearly specified :) Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Christer Holmberg > Sent: Monday, March 04, 2013 4:05 AM > To: Paul Kyzivat; Roberta Presta > Cc: clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets >=20 > Hi, >=20 > >>>>> My proposal is, instead of listing all the captures, using=20 > >>>>> capture scene identifiers and capture scene entry identifiers,=20 > >>>>> and building simultaneous sets as: > >>>>> - CSB, CSC, CSE3_A, CSE1_A > >>>>> - CSB, CSC, CSE3_A, CSE2_A > >>>> So, taking your example, does CSB indicate that I can provide ANY=20 > >>>> CSE associated with CSB, or that I can provide ALL CSEs=20 > >>>> associated with > CSB? > >> > >> Listing a capture scene identifier like CSB in a simultaneous set=20 > >> should mean the provider is able to send simultaneously all the=20 > >> captures within the capture scene entries associated with that=20 > >> capture > scene. > >> Or, at least, that was what I had in mind. > >> It is in line with the current definition of the simultaneous sets=20 > >> (Simultaneous transmission sets are expressed as sets of the Media=20 > >> Captures that could physically be transmitted at the same time). > >> Regards, > > > > Ah, ok - that makes sense. > > > > So referencing a CSE means all the captures in it, and referencing a=20 > > CS means all the CSEs in it. With that interpretation, then=20 > > referencing a CS > could implicitly reference a single capture more than once. So a=20 > corollary is that referencing a single capture more than once is not an e= rror. >=20 > I agree. If you reference a CS, and some capture is used in multiple=20 > associated CSEs, it means that you are able to provide multiple=20 > "instances" of the capture - one for each CSE where it is used. >=20 > The same thing would apply if you reference a CSE, and a capture=20 > within it: it means you are able to provide two "instances" of the captur= e. >=20 > So, while I can't think of any use-case at the moment, I agree that we=20 > should not consider it an error case. But, we need to make sure it's=20 > clearly documented :) >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Mar 6 06:57:47 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 8FCD221F88E5 for ; Wed, 6 Mar 2013 06:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il9Y1aWlkYXq for ; Wed, 6 Mar 2013 06:57:47 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id A25A621F8ADC for ; Wed, 6 Mar 2013 06:57:44 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([::1]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 6 Mar 2013 06:56:25 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 6 Mar 2013 06:57:42 -0800 Thread-Topic: What is the status of draft-groves-clue-capture-attr? Thread-Index: Ac4aeiZ2MsR6qxEYSZmZ2iehtqb6Gg== Message-ID: <9C23AB934B394845A7B228239B6EAF416F09D2@CRPMBOXPRD01.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9C23AB934B394845A7B228239B6EAF416F09D2CRPMBOXPRD01polyc_" MIME-Version: 1.0 Subject: [clue] What is the status of draft-groves-clue-capture-attr? 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, 06 Mar 2013 14:57:47 -0000 --_000_9C23AB934B394845A7B228239B6EAF416F09D2CRPMBOXPRD01polyc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm sorry I missed the previous discussion about this draft. Has the worki= ng group already generally agreed to make changes to the framework (and dat= a model - partly done already) to remove the Content attribute and add all = the attributes proposed in section 4 of this draft? Thanks, Mark --_000_9C23AB934B394845A7B228239B6EAF416F09D2CRPMBOXPRD01polyc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m sorry = I missed the previous discussion about this draft.  Has the working gr= oup already generally agreed to make changes to the framework (and data mod= el – partly done already) to remove the Content attribute and add all= the attributes proposed in section 4 of this draft?

 

Thanks,
Mark=

= --_000_9C23AB934B394845A7B228239B6EAF416F09D2CRPMBOXPRD01polyc_-- From pkyzivat@alum.mit.edu Wed Mar 6 07:13: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 483B521F8C5C for ; Wed, 6 Mar 2013 07:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.147 X-Spam-Level: X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[AWL=0.290, 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 rlD524+o0XSY for ; Wed, 6 Mar 2013 07:13:07 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 67C3A21F8C20 for ; Wed, 6 Mar 2013 07:13:07 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta13.westchester.pa.mail.comcast.net with comcast id 8CZu1l0010QuhwU5DFD6At; Wed, 06 Mar 2013 15:13:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 8FD61l00x3ZTu2S3NFD6lH; Wed, 06 Mar 2013 15:13:06 +0000 Message-ID: <51375D02.5000207@alum.mit.edu> Date: Wed, 06 Mar 2013 23:13:06 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.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=1362582786; bh=E4W7JA2hyvla4BvCOJmwAUlZi400RT/WjhU7jshQ8ks=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=i9kFY6JkENTbwZgYLvorgpVQfVt/KeKg4NQkrNs9CDftQtNcfBNveGvMBJDiX1XZH qX5PhL7bQBCWpfcqTu04IMeDQxYDRALspBL2f9RaLZjpzuADx2SYHbtb1KR50XuNsS 01CG2Fc0F7pGJsI7dhu2cQhkwhuwhgWQ4dFAzR22yZECW1xSajnjo9ezcHE0LDi+O8 ixXBAyanfZ8UfrKkBAaLH/AJ6uvOK7zRPXGROB651/YRyTiqJMYdRD82XCfBPIZVGc WdAciV90p6WKTQe33D5lnRgGaRmPpYCJ3w3VUeagZTLhqMGQ5ZRWUOLre6aYuha07H C4PyKwrGKQSmw== Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 15:13:08 -0000 Mark, I agree with all you say below. But this does lead to another related issue that needs some consideration. Until now I think we have said that a single simultaneous set should mention only a single medium - voice or video. When we permit it to reference a complete scene it will have entries for different kinds of media. So what does that mean? Having simultaneous sets only reference a single medium implies that simultaneity across media types is implicit. I wonder if that is really true. Some possible resolutions to this: 1) keep the current assumption that a simultaneous set applies to only one medium, and to preserve that forbid the inclusion of a complete CS if it contains more than one type of medium. 2) keep the current assumption that a simultaneous set applies to only one medium. If a set contains references to CSs, factor those by media type, and create multiple sets - one for each medium. 3) forbid references to CSs in simultaneous sets 4) change the definition of simultaneous sets so that they explicitly define permitted simultaneity among multiple media types. I haven't decided my own preference among the above. Thanks, Paul On 3/6/13 10:32 PM, Duckworth, Mark wrote: > I will try to summarize what I think the conclusions are from this thread. > > Point 1 - we generally agree simultaneity restrictions are not just about physical constraints, there are other reasons. > > Point 2 - we should remove the bit about "may not make sense to do so". > > Point 3 - we generally agree it would be good to allow expressing Simultaneous Transmission Sets as lists of Capture Sets, Capture Set Entries, as well as Media Captures that the Provider can provide simultaneously. > > Point 4 - we generally agree (again) we do not want to define other ways of expressing Simultaneous Transmission Sets, such as by mutual exclusion or with logical operators. > > Regards, > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Roberta Presta >> Sent: Wednesday, February 27, 2013 1:47 PM >> To: clue@ietf.org >> Subject: [clue] comments to framework 09 - simultaneous sets >> >> Hi all, >> >> sorry for boring you always with the same things :) >> >> When I read Section 6.3 "Simultaneous Transmission Set Constraint", I >> noticed a couple of things: >> >> 1) the only motivation that has been provided to justify the definition of >> simultaneous sets is the fact that captures generated from the same device >> cannot be sent simultaneously. However, there can be other motivations >> behind the need of expressing simultaneity constraints (leaving resource >> constraints handled by encoding groups and other stuff such as max- >> encoding- and so on). >> Citing Andy Pepperel in >> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, >> simultaneous sets can be used by MCUs that might not want to be obliged to >> provide some capture simultaneously, in order to avoid overloading. >> I think that these other motivations should be explicitely mentioned in the >> framework document to explain that simultaneity limitations may not be due >> only to physical constraints. >> >> 2) Copying from the document: "Simultaneous transmission sets are >> expressed as sets of the Media Captures that could physically be transmitted >> at the same time (though it may not make sense to do so). " >> Does it mean that even if there is a large set of captures able to be sent >> simultaneously, it may not make sense, from the consumer's perspective, to >> receive them all together? Maybe rewording is needed here. >> >> 3) Again, on the design (and definition) of the simultaneous sets. >> >> Simultaneous sets, as defined in the framework, are *all* the groups of >> *captures* that can be sent together. >> The consumer presumably has to check if the set of captures he wants is fully >> *included* in almost one of the listed ones. >> If not, he has to re-structure the configure to fit simultaneity constraints >> expressed by the provider. >> (Is that the expected behavior of the consumer?) >> >> I was thinking that each set can be expressed also in terms of capture scene >> entries, or capture scene as a whole, for example: >> 1) CSE1, CSE2, CS3, VC1, CS5 >> 2) CSE1, CSE4, CS3, VC1, CS5 >> .... >> Where CSE* identifies a capture scene entry, and CS* identifies a capture >> scene. >> That can allow to make simultaneous sets more synthetic by exploiting the >> capture aggregates the framework envisions. It can be particularly useful to >> MCUs that want to offer just subsets of the complete list of capture scenes >> they receive from multiple contributors. >> >> >> 4) Some further reasoning. >> >> In some cases it can be more efficient to express only mutual exclusion >> constraints. >> We could discuss about envisioning a section of information named >> "simultaneity constraints" that can include a list of simultaneous sets and a >> list of mutual exclusion conditions to be checked on the consumer's side. >> For example, if a media provider offers many captures, and has only 4 mutual >> exclusion conditions, instead of listing all the possible simultaneous sets, he >> can just provide the 4 mutual exclusion conditions to the consumer. >> >> Another alternative is also Christer Holmberg's proposal in >> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, where >> simultaneity constraints are logical conditions that the consumer has to verify >> before issuing a configure to the provider. >> The example was: >> >> "(CSE-X AND CSE-Y) OR CSE-Z. >> >> This means that the provider can provide CSE-X and CSE Y (and all captures >> associated with CSE-X and CSE-Y) simultaneously, or that the provider can >> provide CSE-Z (and all captures associated with CSE-Z)." >> >> Do you think we should stuck on the framework solution or also consider the >> aforementioned alternatives? >> I promise I stop thinking about it! >> >> RP >> >> -- >> Roberta Presta, Ph.D. Student >> Dipartimento di Ingegneria Elettrica e delle Tecnologie dell'Informazione >> (DIETI) Universita' degli Studi di Napoli "Federico II" >> Via Claudio 21 -- 80125 Napoli (Italy) >> Phone: +390817683821 - Fax: +390817683816 >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Wed Mar 6 07:21:10 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 C5EDF11E80FD for ; Wed, 6 Mar 2013 07:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[AWL=0.276, 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 1Rh2NrmHgghT for ; Wed, 6 Mar 2013 07:21:10 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 6F88121F861F for ; Wed, 6 Mar 2013 07:21:08 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id 8BE61l00627AodY55FM7mg; Wed, 06 Mar 2013 15:21:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 8FM71l00d3ZTu2S3fFM77k; Wed, 06 Mar 2013 15:21:07 +0000 Message-ID: <51375EE3.3020608@alum.mit.edu> Date: Wed, 06 Mar 2013 23:21:07 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> <512FE233.8010104@nteczone.com> <7594FB04B1934943A5C02806D1A2204B10DEE8@ESESSMB209.ericsson.se> <51308DD6.4030309@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539FDE@CRPMBOXPRD01.polycom.com> <7594FB04B1934943A5C02806D1A2204B113AF2@ESESSMB209.ericsson.se> <5137529A.5060402@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B113E6F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B113E6F@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=1362583267; bh=g/CBo81KdO7FuFuypZOWIXmeSMmt11nz0/meeXvOE/M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K1yjydye6Erqj0OISFThc5+ZRsP6T4vfvVH4G435s9l9WZnH06GRMZ/45TvJPbA7n JUtzOk7anz5z+KFf/atHItelMJuIT64i1CTF5jakuhfuHUiISKxaU654VlyEW2y7aW 77Wk6kWRg70ZD8qL0ncQchZ+4KPzLqC+qLiMpF0trdfVw2MD3XMMWcVUtZMXHuxVIE hb5mgbdF61V9NJ/gsNeKmazRVkAeRNTYPChPERNxBoDW5fWC0F9Wm2w/XnhP1zt7fg l2rr5ckXckb89uma6Fb2uNPMVroD+6iZXYXshggvNMckWNaGBtBKPUSFj3RBdmIMoX /Jy5LiEK6BcnA== Cc: "clue@ietf.org" Subject: Re: [clue] Christer's initial comments on framework-09 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, 06 Mar 2013 15:21:10 -0000 On 3/6/13 10:46 PM, Christer Holmberg wrote: > Hi, > >>>> I agree with Christian and Paul about Q1, and think the framework is okay as is. Section 6.2 says " The Capture Scene Entries in a Capture Scene are different alternatives the provider is suggesting for representing the Capture Scene." >>>> >>>> I agree with Christian and Paul about Q2, and think the framework is okay as is regarding the optional Simultaneous Transmission Set. >>> >>> I am ok with providing both CSEs and individual captures. >>> >>> But, we need to make it clear that, if a provider in the same set entry provides both a CSE and a capture, and the capture is also part of the CSE, it provides two "instances" (we can come up with better wording) of the same capture. >> >> Why? I don't think that this necessarily should mean that. >> Providing the same capture multiple times is simulcast, and I thought we were handling that separately via the MaxCaptureEncodings element of the data model. > > So what does it mean? "Unspecified"? "it"? IMO, as Mark said, multiple instances of the same capture in the same simultaneous set mean the same as one instance. And the MaxCaptureEncodings for that, together with the number of available encodings in the encoding group associated with that capture, determine how many encodings of it you can receive. Consider a case where a receiver wants to receive two full CSEs that happen to have a capture in common. It is quite likely that the receiver will only want to receive a single copy of that. Certainly that is likely to be the case for an MCU. Thanks, Paul > Regards, > > Christer > > >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Friday, March 01, 2013 6:16 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] Christer's initial comments on framework-09 >>> >>> On 3/1/13 6:22 PM, Christer Holmberg wrote: >>>> Hi, >>>> >>>>> For Q1 I think the definition of CSE indicates that its an entire scene. >>>> >>>> Yes, the definition is probably ok. I am referring to text elsewhere >>>> in the >>> draft. >>>> >>>>> With respect to Q2, I agree that's why we made the sending of the >>> simultaneous set optional. If the provider doesn't send the STS the >>> consumer assumes that all captures in the CSE can be provided simultaneously. >>>> >>>> EVEN if the provider sends STS, I think a provider MUST be able to >>>> provide >>> a CSE. >>> >>> I think this makes sense, but what to do if the simultaneous set conflicts? >>> >>>> In my opinion, the only use of STS is when one wants to >>>> simultaneously >>> provide captures belonging to different CSE/CS. But, as I indicated >>> earlier, in my opinion is would be better to indicate Simultaneous CSE Set. >>> >>> I disagree, because it may be feasible to provide *some* simultaneity >>> but not be able to provide two complete CSEs simultaneously. >>> >>> Thanks, >>> Paul >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >>>> >>>> On 28/02/2013 11:24 PM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>> A couple of initial comments: >>>>> >>>>> ------------------- >>>>> >>>>> Q1: Capture Scene and Capture Scene Entry editorial >>>>> >>>>> In a few places, there is text saying that "a Capture Scene >>>>> includes one or more Capture Scene Entries". I think that is a >>>>> little misleading, because it sounds like one uses one or more CSEs >>>>> in order to describe a CS. >>>>> >>>>> But, as each single CSE describes the whole scene, I think the text >>>>> should talk about CSEs providing alternatives for providing the CS. >>>>> >>>>> ------------------- >>>>> >>>>> Q2: Simultaneous Transmission Set >>>>> >>>>> We had a long discussion about this some time ago, and we never >>>>> came to a conclusion. I know there is another thread about STSs >>>>> also, and I will reply to that. >>>>> >>>>> But, I think that an endpoint shall always be able to >>>>> simultaneously provide all captures within a given CSE. So, there >>>>> is no need to explicitly advertise that the captures associated >>>>> with a given CSE can be provided simultaneously. >>>>> >>>>> ------------------- >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From roberta.presta@unina.it Wed Mar 6 08:05: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 728B021F85D8 for ; Wed, 6 Mar 2013 08:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFvo3hX9tChf for ; Wed, 6 Mar 2013 08:05:20 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id A72CC21F85D6 for ; Wed, 6 Mar 2013 08:05:19 -0800 (PST) Received: from [127.0.0.1] ([143.225.229.193]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r26G5EAX003162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Mar 2013 17:05:14 +0100 Message-ID: <5137693E.9000306@unina.it> Date: Wed, 06 Mar 2013 17:05:18 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Paul Kyzivat References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> In-Reply-To: <51375D02.5000207@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130306-0, 06/03/2013), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 16:05:20 -0000 Hi Paul, Il 06/03/2013 16:13, Paul Kyzivat ha scritto: > > Until now I think we have said that a single simultaneous set should > mention only a single medium - voice or video. > Even if simultaneous sets examples in the framework document only deal with video captures, it is not stated anywhere that they refer only to a single medium. The current definition says only that they are lists of generic media captures. That's why we put in the data model example both audio and video captures in the simultaneous sets. I don't know if I have missed some thread about it. If so, I apologize. Building separated simultaneous sets on the basis of the captures' medium could bring in some cases the benefit of having shorter lists of captures. However, I think that having the possibility of expressing simultaneous sets by using capture scene identifiers can be useful especially to MCUs dealing with a bulk of contributions from different sites. They can easily and briefly advertise simultaneous aggregates of captures (arranged in capture scenes) according to their internal policies. What are your feelings about it? Roberta From pkyzivat@alum.mit.edu Wed Mar 6 08:51:06 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 5782D21F8A6E for ; Wed, 6 Mar 2013 08:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.173 X-Spam-Level: X-Spam-Status: No, score=-0.173 tagged_above=-999 required=5 tests=[AWL=0.264, 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 ycXUYPwKtBzy for ; Wed, 6 Mar 2013 08:51:05 -0800 (PST) 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 22C0421F8A51 for ; Wed, 6 Mar 2013 08:51:02 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id 8E5q1l0081swQuc5FGr2Gr; Wed, 06 Mar 2013 16:51:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id 8Gr21l00X3ZTu2S3bGr2Qk; Wed, 06 Mar 2013 16:51:02 +0000 Message-ID: <513773F4.3040009@alum.mit.edu> Date: Thu, 07 Mar 2013 00:51:00 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Roberta Presta References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <5137693E.9000306@unina.it> In-Reply-To: <5137693E.9000306@unina.it> 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=1362588662; bh=9vghgCJP/uJRS+AfAfhgJ/fdxZLJ6kB7Cfsw7uGX5S4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=jCdLKGFixZsavxkZqXNRUg6WWaxilKWx9UUCfdosPdCVXRKqlyrADtS/m2WWd3Jh9 ePcE7210XHMMj5Y60YhVaM9BiLEj/4BDPIxewQoWu9IYduRWuRJO9DIPq8HRMk92o7 nwfjtsSunoJTHYdAHi+CUl8ab/s1Y7Tq5a8XwRlrOwKnWELdwkeg2AxDs4jIOSYeoi a6o2MPiQShpjT/gcJTPXpCojeVOsnTaQ3bG4XnR7x9xO4yIy0Od7SkqRAKZ3/pjUlP WX0UJLLVoAIcrfGILinP6vdtIUk/wQUukCzKIhUVJnJT9TkC9mhcvYKh/1JnkzYkyB M8CY5a0Ih7GqQ== Cc: clue@ietf.org Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 16:51:06 -0000 On 3/7/13 12:05 AM, Roberta Presta wrote: > Hi Paul, > > Il 06/03/2013 16:13, Paul Kyzivat ha scritto: >> >> Until now I think we have said that a single simultaneous set should >> mention only a single medium - voice or video. >> > > Even if simultaneous sets examples in the framework document only deal > with video captures, it is not stated anywhere that they refer only to a > single medium. > The current definition says only that they are lists of generic media > captures. > That's why we put in the data model example both audio and video > captures in the simultaneous sets. > I don't know if I have missed some thread about it. If so, I apologize. > > Building separated simultaneous sets on the basis of the captures' > medium could bring in some cases the benefit of having shorter lists of > captures. > However, I think that having the possibility of expressing simultaneous > sets by using capture scene identifiers can be useful especially to MCUs > dealing with a bulk of contributions from different sites. They can > easily and briefly advertise simultaneous aggregates of captures > (arranged in capture scenes) according to their internal policies. > > What are your feelings about it? I generally expressed my thinking in the list of possibilities I provided. I guess that theoretically I would prefer that the simultaneous sets include multiple media. But from a practical perspective that might be cumbersome to specify. Allowing reference of CSEs and CSs is likely to make it less cumbersome in many cases. But I am interested to hear if anyone sees realistic case where the simultaneous sets involving multiple media would be impractically large. Thanks, Paul From Mark.Duckworth@polycom.com Wed Mar 6 10:48:21 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 6FE8F21F8C06 for ; Wed, 6 Mar 2013 10:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 D1HZUy4VFyiV for ; Wed, 6 Mar 2013 10:48:17 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 9A16621F86B6 for ; Wed, 6 Mar 2013 10:48:16 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([::1]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Wed, 6 Mar 2013 10:46:58 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 6 Mar 2013 10:48:16 -0800 Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: Ac4ahHCm/VEaxm9GRwSK+fZb9w4DgQAFls3A Message-ID: <9C23AB934B394845A7B228239B6EAF416F0B6E@CRPMBOXPRD01.polycom.com> References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <5137693E.9000306@unina.it> In-Reply-To: <5137693E.9000306@unina.it> 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] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:48:21 -0000 Roberta wrote: > Even if simultaneous sets examples in the framework document only deal > with video captures, it is not stated anywhere that they refer only to a = single > medium. It is stated in section 6.3: "This type of constraint is expressed in a Simultaneous Transmission Set, w= hich lists all the Captures of a particular media type (e.g. audio, video, = text) that can be sent at the same time." This is supposed to mean each Simultaneous Transmission Set includes only o= ne media type. If this isn't clear, we can make it more clear. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roberta Presta > Sent: Wednesday, March 06, 2013 11:05 AM > To: Paul Kyzivat > Cc: clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets >=20 > Hi Paul, >=20 > Il 06/03/2013 16:13, Paul Kyzivat ha scritto: > > > > Until now I think we have said that a single simultaneous set should > > mention only a single medium - voice or video. > > >=20 > Even if simultaneous sets examples in the framework document only deal > with video captures, it is not stated anywhere that they refer only to a = single > medium. > The current definition says only that they are lists of generic media cap= tures. > That's why we put in the data model example both audio and video capture= s > in the simultaneous sets. > I don't know if I have missed some thread about it. If so, I apologize. >=20 > Building separated simultaneous sets on the basis of the captures' > medium could bring in some cases the benefit of having shorter lists of > captures. > However, I think that having the possibility of expressing simultaneous s= ets > by using capture scene identifiers can be useful especially to MCUs deali= ng > with a bulk of contributions from different sites. They can easily and br= iefly > advertise simultaneous aggregates of captures (arranged in capture scenes= ) > according to their internal policies. >=20 > What are your feelings about it? >=20 > Roberta >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Mar 6 10:58:21 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 525B721F8C84 for ; Wed, 6 Mar 2013 10:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 c7NH8HUwsuzC for ; Wed, 6 Mar 2013 10:58:17 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F080521F8C83 for ; Wed, 6 Mar 2013 10:58:16 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([::1]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 6 Mar 2013 10:58:16 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 6 Mar 2013 10:58:16 -0800 Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: Ac4afR9N34J7TzECTBCedy4l/4dRNwAHyxHw Message-ID: <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> In-Reply-To: <51375D02.5000207@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] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 18:58:21 -0000 Hi Paul, I was assuming your item 2 is what we would do. But it could be open for d= iscussion. > 2) keep the current assumption that a simultaneous set applies to only on= e > medium. If a set contains references to CSs, factor those by media type, = and > create multiple sets - one for each medium. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, March 06, 2013 10:13 AM > To: clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets >=20 > Mark, >=20 > I agree with all you say below. >=20 > But this does lead to another related issue that needs some consideration= . > Until now I think we have said that a single simultaneous set should ment= ion > only a single medium - voice or video. When we permit it to reference a > complete scene it will have entries for different kinds of media. So what= does > that mean? >=20 > Having simultaneous sets only reference a single medium implies that > simultaneity across media types is implicit. I wonder if that is really t= rue. >=20 > Some possible resolutions to this: >=20 > 1) keep the current assumption that a simultaneous set applies to only on= e > medium, and to preserve that forbid the inclusion of a complete CS if it > contains more than one type of medium. >=20 > 2) keep the current assumption that a simultaneous set applies to only on= e > medium. If a set contains references to CSs, factor those by media type, = and > create multiple sets - one for each medium. >=20 > 3) forbid references to CSs in simultaneous sets >=20 > 4) change the definition of simultaneous sets so that they explicitly def= ine > permitted simultaneity among multiple media types. >=20 > I haven't decided my own preference among the above. >=20 > Thanks, > Paul >=20 >=20 >=20 > On 3/6/13 10:32 PM, Duckworth, Mark wrote: > > I will try to summarize what I think the conclusions are from this thre= ad. > > > > Point 1 - we generally agree simultaneity restrictions are not just abo= ut > physical constraints, there are other reasons. > > > > Point 2 - we should remove the bit about "may not make sense to do so". > > > > Point 3 - we generally agree it would be good to allow expressing > Simultaneous Transmission Sets as lists of Capture Sets, Capture Set Entr= ies, > as well as Media Captures that the Provider can provide simultaneously. > > > > Point 4 - we generally agree (again) we do not want to define other way= s of > expressing Simultaneous Transmission Sets, such as by mutual exclusion or > with logical operators. > > > > Regards, > > Mark > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > >> Of Roberta Presta > >> Sent: Wednesday, February 27, 2013 1:47 PM > >> To: clue@ietf.org > >> Subject: [clue] comments to framework 09 - simultaneous sets > >> > >> Hi all, > >> > >> sorry for boring you always with the same things :) > >> > >> When I read Section 6.3 "Simultaneous Transmission Set Constraint", I > >> noticed a couple of things: > >> > >> 1) the only motivation that has been provided to justify the > >> definition of simultaneous sets is the fact that captures generated > >> from the same device cannot be sent simultaneously. However, there > >> can be other motivations behind the need of expressing simultaneity > >> constraints (leaving resource constraints handled by encoding groups > >> and other stuff such as max- > >> encoding- and so on). > >> Citing Andy Pepperel in > >> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, > >> simultaneous sets can be used by MCUs that might not want to be > >> obliged to provide some capture simultaneously, in order to avoid > overloading. > >> I think that these other motivations should be explicitely mentioned > >> in the framework document to explain that simultaneity limitations > >> may not be due only to physical constraints. > >> > >> 2) Copying from the document: "Simultaneous transmission sets are > >> expressed as sets of the Media Captures that could physically be > >> transmitted at the same time (though it may not make sense to do so). = " > >> Does it mean that even if there is a large set of captures able to be > >> sent simultaneously, it may not make sense, from the consumer's > >> perspective, to receive them all together? Maybe rewording is needed > here. > >> > >> 3) Again, on the design (and definition) of the simultaneous sets. > >> > >> Simultaneous sets, as defined in the framework, are *all* the groups > >> of > >> *captures* that can be sent together. > >> The consumer presumably has to check if the set of captures he wants > >> is fully > >> *included* in almost one of the listed ones. > >> If not, he has to re-structure the configure to fit simultaneity > >> constraints expressed by the provider. > >> (Is that the expected behavior of the consumer?) > >> > >> I was thinking that each set can be expressed also in terms of > >> capture scene entries, or capture scene as a whole, for example: > >> 1) CSE1, CSE2, CS3, VC1, CS5 > >> 2) CSE1, CSE4, CS3, VC1, CS5 > >> .... > >> Where CSE* identifies a capture scene entry, and CS* identifies a > >> capture scene. > >> That can allow to make simultaneous sets more synthetic by exploiting > >> the capture aggregates the framework envisions. It can be > >> particularly useful to MCUs that want to offer just subsets of the > >> complete list of capture scenes they receive from multiple contributor= s. > >> > >> > >> 4) Some further reasoning. > >> > >> In some cases it can be more efficient to express only mutual > >> exclusion constraints. > >> We could discuss about envisioning a section of information named > >> "simultaneity constraints" that can include a list of simultaneous > >> sets and a list of mutual exclusion conditions to be checked on the > consumer's side. > >> For example, if a media provider offers many captures, and has only 4 > >> mutual exclusion conditions, instead of listing all the possible > >> simultaneous sets, he can just provide the 4 mutual exclusion conditio= ns > to the consumer. > >> > >> Another alternative is also Christer Holmberg's proposal in > >> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, > >> where simultaneity constraints are logical conditions that the > >> consumer has to verify before issuing a configure to the provider. > >> The example was: > >> > >> "(CSE-X AND CSE-Y) OR CSE-Z. > >> > >> This means that the provider can provide CSE-X and CSE Y (and all > >> captures associated with CSE-X and CSE-Y) simultaneously, or that the > >> provider can provide CSE-Z (and all captures associated with CSE-Z)." > >> > >> Do you think we should stuck on the framework solution or also > >> consider the aforementioned alternatives? > >> I promise I stop thinking about it! > >> > >> RP > >> > >> -- > >> Roberta Presta, Ph.D. Student > >> Dipartimento di Ingegneria Elettrica e delle Tecnologie > >> dell'Informazione > >> (DIETI) Universita' degli Studi di Napoli "Federico II" > >> Via Claudio 21 -- 80125 Napoli (Italy) > >> Phone: +390817683821 - Fax: +390817683816 > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed Mar 6 16:17:26 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 D658111E80BF for ; Wed, 6 Mar 2013 16:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 F8FMteMVs7GP for ; Wed, 6 Mar 2013 16:17:26 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 27A2211E809C for ; Wed, 6 Mar 2013 16:17:26 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id v28so1632111qcm.39 for ; Wed, 06 Mar 2013 16:17:25 -0800 (PST) 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:cc:content-type; bh=U2dLhdYjgxd49B2wN5w2nGai6sLDlX9Q5Sq0+Do0IEo=; b=onNWBqjc7n66X2gP4NOFR58ENKkXQr1qQZp9e5ZJ78d4BUyuuzA1h6j639xRwLNNHR dOeaTBqXLHwPEx63zgZLXj1QidDapVww8YyBOWZ9I2cZb9JceBxbgpfGlnR7xwwF87AH LiKOfbm92wEeJK4YTeVJD8li7qnT0lEvhKOaVHNX3jOMifN/Lpo5AEnG6BKodlZAjc9O swNDySIBxPflWl5Fnu+PbEyANgXuqblNdRFmf0xQOoVDd8QkFMFCPPNrQ6KO0ozbd7+h tx9+yV79f7skvEzfSUPdQAFZw6DM4r0yArAz3kr/RVltSQH42xyz+BO8xdZhNrU+ZEzM 9eYQ== MIME-Version: 1.0 X-Received: by 10.224.186.212 with SMTP id ct20mr4633536qab.3.1362615445584; Wed, 06 Mar 2013 16:17:25 -0800 (PST) Received: by 10.49.24.130 with HTTP; Wed, 6 Mar 2013 16:17:25 -0800 (PST) In-Reply-To: References: Date: Wed, 6 Mar 2013 18:17:25 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th 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, 07 Mar 2013 00:17:27 -0000 Hi all, Here is a summary of Monday's meeting. Attendees: Mary Barnes, Mark Duckworth, Rob Hansen, Paul Kyzivat, Simon Pietro-Romano Notes: --------- The objective of the meeting was to review the plans and areas of focus for IETF-86. Framework: - with regards to Stephan's portion on the agenda, the expectation was to get an update on the rework and way forward. - we discussed the incorporation of Christian's suggestions (per the discussion of draft ) into the framework. Action: Mark to review and determine if/what changes are required for the framework - Mark noted that there are some issues in the tracker that should be closed. Action: chairs review emails and close related issues - Simultaneous sets: it appears the discussion on the list is converging. Mark: review and determine framework impacts. - Paul noted that Stephan had sent an email on FW issues, most of which really need to be resolved in solution documents Signaling/solution: - Note that Jonathan has produced a draft which was a result of the action item from IETF-85 for the RTCWEB/CLUE folks to work together for a model for RTP: http://www.ietf.org/id/draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt - In terms of the Signaling portion of the agenda on Tuesday, Paul will provide an overview/update on the current signaling solution document. That will lead into Rob's draft specifically analyzing SDP usage. Also, folks should read this document which identifies requirements some of which are applicable to CLUE: http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 It is on the MMUSIC WG agenda for discussion on Friday: https://datatracker.ietf.org/meeting/86/agenda/mmusic/ Regards, Mary. From Christian.Groves@nteczone.com Wed Mar 6 19:21:29 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 7987511E80D2 for ; Wed, 6 Mar 2013 19:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvTNji5-HRUP for ; Wed, 6 Mar 2013 19:21:28 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 8206711E80C5 for ; Wed, 6 Mar 2013 19:21:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAsHOFF20fju/2dsb2JhbAANLArERoF6gx4BAQEEAQEBNRsbChELGAkWDwkDAgECARUwEwYCAQGIG6dRk2gEjUoHgUIWgyoDqlg Received: from ppp118-209-248-238.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.248.238]) by ipmail07.adl2.internode.on.net with ESMTP; 07 Mar 2013 13:51:27 +1030 Message-ID: <513807AE.1050303@nteczone.com> Date: Thu, 07 Mar 2013 14:21:18 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512A9240.3040800@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539E39@CRPMBOXPRD01.polycom.com> <5136224C.4020000@alum.mit.edu> In-Reply-To: <5136224C.4020000@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] New framework I-D posted 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, 07 Mar 2013 03:21:29 -0000 Hello, Please see my responses below marked [CNG]. Regards, Christian On 6/03/2013 3:50 AM, Paul Kyzivat wrote: > On 3/5/13 7:06 AM, Duckworth, Mark wrote: > > Trimming > >>> It was my understanding that we were not advocating doing anything >>> that is >>> contrary to the negotiated SDP. (E.g. using a codec not mentioned in >>> the >>> SDP.) But there are still plenty of changes that could potentially >>> be made >>> without violating the current SDP. E.g. selecting a new >>> capture-encoding that >>> uses an m-line that is already compatible. >> >> [Duckworth, Mark] I agree, Paul. If this is what the group wants, >> the framework document should clearly say CLUE devices follow all SDP >> O/A rules. Should we also refer to some specific RFCs? > > Since we are talking about SDP, we can at least reference 4566 and > draft-ietf-mmusic-rfc4566bis. I don't think we need to mention any SDP > extensions here unless we have reason to talk about them explicitly. [CNG] I'd be a little hesitant to mandate that a devices supporting CLUE must support SDP O/A. That may not make much sense for non-SIP devices. Yes I know this working group is only working on SIP CLUE but the charter says we should identify interoperability obstacles in existing open standards > >>> Section 6.2.2: >>> >>> While it makes sense to outsource the detailed attributes here, IMO >>> it is NOT >>> ok to defer the definition of switching and composition to the data >>> model. >>> There should be a discussion of the concepts of that *somewhere*, and I >>> can't think of a better place than the FW. For instance, the difference >>> between site switching and segment switching, and the difference >>> between >>> switching and composition. (And of course that these have some >>> differences >>> between audio and video.) >> >> [Duckworth, Mark] I'm not sure exactly where to draw the line about >> which things go in which document. Site switch and segment switch >> description actually came from the use case document, we just >> repeated it in the framework. Are you suggesting we just keep in the >> framework some of the text about switching and composition that was >> already in the framework? And not move so much of it to another >> document? > > I don't think we define them very well at all. > So we probably need some new text. Maybe somebody has a better idea, > but ISTM that these are *concepts* that need to be explained. People > may have a general notion from the names, but we should be more > precise than that. Especially in the case of switching, this later > becomes fundamental to the notions of dynamic and static mapping. [CNG] I agree. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Mar 6 20:09: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 0EBDE21F87D2 for ; Wed, 6 Mar 2013 20:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKoYjKh2oG57 for ; Wed, 6 Mar 2013 20:09:49 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE5521F8765 for ; Wed, 6 Mar 2013 20:09:48 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALAROFF20fju/2dsb2JhbAANNsRGgXqDHgEBAQMBOBslARALIRYPCQMCAQIBRQYNAQcBARWHdKdvk2+NVYE3B4NAA6pYgVU Received: from ppp118-209-248-238.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.248.238]) by ipmail07.adl2.internode.on.net with ESMTP; 07 Mar 2013 14:39:46 +1030 Message-ID: <51381304.7010706@nteczone.com> Date: Thu, 07 Mar 2013 15:09:40 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Duckworth, Mark" References: <512EF700.2080207@nteczone.com> <9C23AB934B394845A7B228239B6EAF41539E72@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF41539E72@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] New framework I-D posted 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, 07 Mar 2013 04:09:50 -0000 Hello Mark, Please see my responses below. Regards, Christian ..snip The latest version looks pretty good, I've reviewed it and have the following comments/questions. Section 1, Pg.3 bullet (3) - It talks about "chosen by operator" perhaps as the next part talks about "consumer" it should say "chosen by provider". > [Duckworth, Mark] I'm not sure what you mean. Are you talking about page 4, paragraph numbered (2)? What do you suggest changing? [CNG] Sorry it should be bullet (2). The comment is that the draft uses the terms "Provider" and "Consumer". Whereas this point talks about "operator". An operator could be at either a provider endpoint or consumer endpoint. I think that its probably easier to say: "The Capture Scene concept allows for the description of multiple setups for those multiple capture devices that could represent sensible operation points of the physical capture devices in a room, chosen by the <>." > >> Section 1, Pg.3 bullet (3) - Simultaneous capture sets are actually above the >> capture scene description. Not part of the capture scene description. This is >> due to the ability to indicate simultaneity requirements between all capture >> scenes in an advertisement. i.e. from >> v8 "These simultaneous set constraints apply across >> all the captures scenes in the advertisement." > [Duckworth, Mark] I think it should just say "Simultaneous capture sets are discussed in section 6.3", removing the incorrect part about being part of a Capture Scene. [CNG] OK > >> Section 1, Pg.3 bullet (5) - Why do we have the "sales pitch" :-) for RTP >> multiplexing in motivation for CLUE? Isn't the key point that CLUE allows for >> the possible reduction of RTP flows? >> >> Section 3 Advertisement: Is this missing description of the aspect of "capture >> scenes" and "captures" etc? The definition seems to on the stream where >> the importance of the CLUE advertisement is really to signal the interrelation >> between the different media captures/streams. > [Duckworth, Mark] "describing specific aspects of the content of the media" is referring to the Captures and Capture Scene information. That's how I read it anyway. [CNG] When you say "content of media" I think "a=content:". I think what CLUE is doing is more than what is in the stream it describes the context of a stream. > >> General: The framework pretty much ties Capture/Capture encoding to RTP >> only. Thinking out aloud could this be a restriction when considering captures >> relating to presentations? > [Duckworth, Mark] I believe the scope of all this is limited to media streams over RTP. [CNG] Yes the charter says that we are concentrating on RTP. However I wonder what in the current framework limits us to RTP? We don't have any RTP specific information in the CLUE protocol as it currently stands. > >> General: Text capture: According to our definitions CLUE support Text >> captures. i.e. Media indicates the possibility of timed text, A media capture >> indicates that its the source of "media". We also talk about streams being >> RTP. Sect 6.3 also talks about captures of a particular type (audio, video, >> text). If we are supporting it then we may be a "Text Capture" (TC). This may >> be an issue for Orlando. > [Duckworth, Mark] I agree we should include text, and possibly other types of media but I don't have any specific examples. Maybe this issue is a more for the data model, to make sure it doesn't exclude other media types that go over RTP? [CNG] I think the framework drives the data model. Thus if we allow different media types we should have some text to describe the other possibilities. For example: This framework uses audio captures and video captures to illustrate the CLUE protocol procedures. Capture types for other RTP based media such as text captures are possible. > >> Section 4 Figure: In the signalling document it shows ACKs to the >> Advertisement and Configure messages. Do we want to show those in the >> framework or at least say for brevity acknowledgements aren't shown? > [Duckworth, Mark] I think after we get a somewhat stable signaling document we should make sure all the documents are consistent. [CNG] Agreed > >> Section 5: With respect to the coordinate system and the origin. We say that >> the location of the origin is up to the provider's choosing. Would it be >> beneficial to suggest a location for it? >> >> Section 6.1.1: It says that capture attributes provide "static" >> information? What is meant by static here? Is it for the life of the CLUE >> association. Static until the next Advertisement is sent? I suggest deleting it. > [Duckworth, Mark] I think anything can change from one advertisement to the next, so I agree we should delete the word "static". [CNG] OK > ..snip >> Section 6.2 Pg.19 Para.4: I'm not sure this reflects the discussions we've had >> on the list. It basically says says that the consumer can do what ever it likes. I >> thought there was some agreement that the consumer SHOULD chose a CSE >> and that these were alternate representation of the entire scene (at least >> according to the scene definition). Section 6.3 mentions choosing only one >> CSE. > [Duckworth, Mark] Yes, the Consumer can choose whatever it wants, subject to constraints of the advertisement. Section 6.3 says "... the Consumer should choose one Capture Scene Entry for each media type, but may choose individual Captures based on the Simultaneous Transmission Sets." I think the framework is saying what we agreed on the list. But maybe not clearly enough? Do you have a specific suggestion? [CNG] I think the aspect of STSs is missing from the part of 6.2. the consumer. The consumer pick and choose Media Captures regardless of how the provider arranges them in CSE, within the scope of an STS. > >> Section 6.2.1: Like above I think its worth having some description in the >> framework document. You should need to look into two documents to get >> the gist of what CLUE is doing. >> >> Section 6.2.1 Area of scene: If this is specified I take it that it must be greater >> than or equal to the outer extents of the individual captures? If it was smaller >> what would it mean? > [Duckworth, Mark] Yes, I think it should be greater than or equal to the outer extents of the individual captures. [CNG] I agree. Maybe we should add this to the framework? > >> Section 6.2.2: Should the scene switch policy be at a Capture scene level? For >> example if we allow the consumer to cherry pick captures from different >> CSEs what happens? Are the capture only related to a CSE switched together >> or all captures related to the scene switched? > [Duckworth, Mark] Good question. Related to Paul's question about picking different CSEs for different media types, which could have different values for the scene-switch-policy. > >> Section 7.1 Pg26.: We can probably remove "Clue-protocol internal >> information" from the list of video codec specific parameters. > [Duckworth, Mark] I agree that doesn't add any value here. Specifics would be in the data model, I think. [CNG] OK > >> Section 8. : It says that every capture is associated with an encoding group. >> Does that mean a provider is REQUIRED to provide maximum the various >> maximum information? I couldn't find any text which suggests sending of >> encoding parameters is optional. > [Duckworth, Mark] Yes, my understanding is it is required. [CNG] So an encoding is mandatory and the indicated parameters are also mandatory for a particular media type? How about maxH264Mbps? What if I'm not using H264? Also the maxGroup??? parameters even if this equals or exceeds the individual values it has to be sent? > >> Section 9. pg. 32 para.4: Not sure that each Advertise is acknowledged by a >> Configure. Acknowledge of the receipt of a message and configuration could >> be separate. > [Duckworth, Mark] The intent is to say something like the Consumer must send a new Configure in response to receiving an Advertisement. Does that make more sense? I agree this could be separate from acknowledging receipt of the Advertisement. [CNG] For the initial Advertisement the Consumer must send a Configure. For subsequent Advertisements the consumer only has to send a Configure if something in the new Advertisement has changed the consumer state and it needs to send a Configure. The consumer should always ack/nack the reception of an Advertisement. > > ..snip From Christian.Groves@nteczone.com Wed Mar 6 20:52: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 2AFFF21F8526 for ; Wed, 6 Mar 2013 20:52:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKr2FxDRrYrx for ; Wed, 6 Mar 2013 20:52:55 -0800 (PST) Received: from ipmail07.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 9875C11E80A3 for ; Wed, 6 Mar 2013 20:52:54 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAJ0cOFF20fju/2dsb2JhbAANNsRGgXqDHgEBAQQBAQE1GxsCCA0CAgsRBAEBAQkWCAcJAwIBAgEJDB8JCBMGAgEBBRKIBKdhk20EjVeBJhIGgzoDkweXUYFe Received: from ppp118-209-248-238.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.248.238]) by ipmail07.adl2.internode.on.net with ESMTP; 07 Mar 2013 15:22:30 +1030 Message-ID: <51381D05.3090101@nteczone.com> Date: Thu, 07 Mar 2013 15:52:21 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 04:52:56 -0000 Hello, I agree with Mark's original conclusions. I also tend to agree with item 2 below. Regards, Christian On 7/03/2013 5:58 AM, Duckworth, Mark wrote: > Hi Paul, > > I was assuming your item 2 is what we would do. But it could be open for discussion. > >> 2) keep the current assumption that a simultaneous set applies to only one >> medium. If a set contains references to CSs, factor those by media type, and >> create multiple sets - one for each medium. > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Wednesday, March 06, 2013 10:13 AM >> To: clue@ietf.org >> Subject: Re: [clue] comments to framework 09 - simultaneous sets >> >> Mark, >> >> I agree with all you say below. >> >> But this does lead to another related issue that needs some consideration. >> Until now I think we have said that a single simultaneous set should mention >> only a single medium - voice or video. When we permit it to reference a >> complete scene it will have entries for different kinds of media. So what does >> that mean? >> >> Having simultaneous sets only reference a single medium implies that >> simultaneity across media types is implicit. I wonder if that is really true. >> >> Some possible resolutions to this: >> >> 1) keep the current assumption that a simultaneous set applies to only one >> medium, and to preserve that forbid the inclusion of a complete CS if it >> contains more than one type of medium. >> >> 2) keep the current assumption that a simultaneous set applies to only one >> medium. If a set contains references to CSs, factor those by media type, and >> create multiple sets - one for each medium. >> >> 3) forbid references to CSs in simultaneous sets >> >> 4) change the definition of simultaneous sets so that they explicitly define >> permitted simultaneity among multiple media types. >> >> I haven't decided my own preference among the above. >> >> Thanks, >> Paul >> >> >> >> On 3/6/13 10:32 PM, Duckworth, Mark wrote: >>> I will try to summarize what I think the conclusions are from this thread. >>> >>> Point 1 - we generally agree simultaneity restrictions are not just about >> physical constraints, there are other reasons. >>> Point 2 - we should remove the bit about "may not make sense to do so". >>> >>> Point 3 - we generally agree it would be good to allow expressing >> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set Entries, >> as well as Media Captures that the Provider can provide simultaneously. >>> Point 4 - we generally agree (again) we do not want to define other ways of >> expressing Simultaneous Transmission Sets, such as by mutual exclusion or >> with logical operators. >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>>> Of Roberta Presta >>>> Sent: Wednesday, February 27, 2013 1:47 PM >>>> To: clue@ietf.org >>>> Subject: [clue] comments to framework 09 - simultaneous sets >>>> >>>> Hi all, >>>> >>>> sorry for boring you always with the same things :) >>>> >>>> When I read Section 6.3 "Simultaneous Transmission Set Constraint", I >>>> noticed a couple of things: >>>> >>>> 1) the only motivation that has been provided to justify the >>>> definition of simultaneous sets is the fact that captures generated >>>> from the same device cannot be sent simultaneously. However, there >>>> can be other motivations behind the need of expressing simultaneity >>>> constraints (leaving resource constraints handled by encoding groups >>>> and other stuff such as max- >>>> encoding- and so on). >>>> Citing Andy Pepperel in >>>> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, >>>> simultaneous sets can be used by MCUs that might not want to be >>>> obliged to provide some capture simultaneously, in order to avoid >> overloading. >>>> I think that these other motivations should be explicitely mentioned >>>> in the framework document to explain that simultaneity limitations >>>> may not be due only to physical constraints. >>>> >>>> 2) Copying from the document: "Simultaneous transmission sets are >>>> expressed as sets of the Media Captures that could physically be >>>> transmitted at the same time (though it may not make sense to do so). " >>>> Does it mean that even if there is a large set of captures able to be >>>> sent simultaneously, it may not make sense, from the consumer's >>>> perspective, to receive them all together? Maybe rewording is needed >> here. >>>> 3) Again, on the design (and definition) of the simultaneous sets. >>>> >>>> Simultaneous sets, as defined in the framework, are *all* the groups >>>> of >>>> *captures* that can be sent together. >>>> The consumer presumably has to check if the set of captures he wants >>>> is fully >>>> *included* in almost one of the listed ones. >>>> If not, he has to re-structure the configure to fit simultaneity >>>> constraints expressed by the provider. >>>> (Is that the expected behavior of the consumer?) >>>> >>>> I was thinking that each set can be expressed also in terms of >>>> capture scene entries, or capture scene as a whole, for example: >>>> 1) CSE1, CSE2, CS3, VC1, CS5 >>>> 2) CSE1, CSE4, CS3, VC1, CS5 >>>> .... >>>> Where CSE* identifies a capture scene entry, and CS* identifies a >>>> capture scene. >>>> That can allow to make simultaneous sets more synthetic by exploiting >>>> the capture aggregates the framework envisions. It can be >>>> particularly useful to MCUs that want to offer just subsets of the >>>> complete list of capture scenes they receive from multiple contributors. >>>> >>>> >>>> 4) Some further reasoning. >>>> >>>> In some cases it can be more efficient to express only mutual >>>> exclusion constraints. >>>> We could discuss about envisioning a section of information named >>>> "simultaneity constraints" that can include a list of simultaneous >>>> sets and a list of mutual exclusion conditions to be checked on the >> consumer's side. >>>> For example, if a media provider offers many captures, and has only 4 >>>> mutual exclusion conditions, instead of listing all the possible >>>> simultaneous sets, he can just provide the 4 mutual exclusion conditions >> to the consumer. >>>> Another alternative is also Christer Holmberg's proposal in >>>> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, >>>> where simultaneity constraints are logical conditions that the >>>> consumer has to verify before issuing a configure to the provider. >>>> The example was: >>>> >>>> "(CSE-X AND CSE-Y) OR CSE-Z. >>>> >>>> This means that the provider can provide CSE-X and CSE Y (and all >>>> captures associated with CSE-X and CSE-Y) simultaneously, or that the >>>> provider can provide CSE-Z (and all captures associated with CSE-Z)." >>>> >>>> Do you think we should stuck on the framework solution or also >>>> consider the aforementioned alternatives? >>>> I promise I stop thinking about it! >>>> >>>> RP >>>> >>>> -- >>>> Roberta Presta, Ph.D. Student >>>> Dipartimento di Ingegneria Elettrica e delle Tecnologie >>>> dell'Informazione >>>> (DIETI) Universita' degli Studi di Napoli "Federico II" >>>> Via Claudio 21 -- 80125 Napoli (Italy) >>>> Phone: +390817683821 - Fax: +390817683816 >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Mar 7 00:19:14 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 DBF5721F8C59 for ; Thu, 7 Mar 2013 00:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agSInRX8tFDu for ; Thu, 7 Mar 2013 00:19:14 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4C521F8C58 for ; Thu, 7 Mar 2013 00:19:13 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-db-51384d80a585 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.43.10459.08D48315; Thu, 7 Mar 2013 09:19:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 09:19:11 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkA== Date: Thu, 7 Mar 2013 08:19:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B11458FESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+JvjW6Dr0Wgwf4Zshb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvNjc9kK9ihUXH3xib2Bca1MFyMnh4SAicTRP6/ZIGwxiQv3 1gPZXBxCAocYJVZdaGaFcBYxShx5+IOxi5GDg03AQqL7nzZIg4iAssTRzf1gzcIC8hIXX11h g4irSKw+9YIdwtaTWPH9LyuIzQIS/3+GBcTmFfCWWHrkDpjNCLT4+6k1TCA2s4C4xK0n85kg DhKQWLLnPDOELSrx8vE/VghbUeLq9OVQ9fkSC34dZoaYKShxcuYTlgmMQrOQjJqFpGwWkjKI uI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73ccBMjMOwPbvmtu4Px1DmRQ4zS HCxK4rxhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCqWdmpiajFMkVZHwubcfo2R8av ZrHdfueXhuqGugmv2r7zfeTuV1I/lX0vb/VQZ3Wavfsud8KjXL6H7/gWa2+fvUJ4nZD7pBnL rQsXufX4Xd26+kyqtv+KFWzZrr2xzVMVGx4diH//nvUkK6PT1yXXzfyu/hYRuNxV9PlfntDf y+HhHbM/L92ixFKckWioxVxUnAgA9jRj+EkCAAA= Subject: [clue] Active speaker a role? 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, 07 Mar 2013 08:19:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B11458FESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and = provides the active speaker to a single screen entity. So, the content will= change as the most active changes, but the capture provided by the MCU wil= l be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement p= hase. Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the "active speaker" role. Or? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B11458FESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A couple of questions related to the capture attribu= te draft.

 

Q1.

 

Assume you have a MCU, which collects streams from m= ultiple endpoints, and provides the active speaker to a single screen entit= y. So, the content will change as the most active changes, but the capture = provided by the MCU will be the same.

 

So, the “role” of this capture would be = “active speaker”. Or?

 

 

Q2.

 

I assume that capture attribute can also be used dur= ing the advertisement phase. Ie a single entity can indicate that it is abl= e to receive a stream, where it want the content to be the “active sp= eaker” role. Or?

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B11458FESESSMB209ericsso_-- From ron.even.tlv@gmail.com Thu Mar 7 00:43: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 429B721F89B3 for ; Thu, 7 Mar 2013 00:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejn5N+UQwJnl for ; Thu, 7 Mar 2013 00:43:17 -0800 (PST) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7322721F89AF for ; Thu, 7 Mar 2013 00:43:17 -0800 (PST) Received: by mail-ee0-f51.google.com with SMTP id d17so112848eek.38 for ; Thu, 07 Mar 2013 00:43:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=j6w6CtpCe4iLCHozli1F7/+DV/D51xgynkRSIGmJ9LA=; b=Int6/ESfekNBr0HnubUKnhI3QyIhXJH6yCpbVc6Ctw1sgt5kjrog2e+CzpBa5TueSV uMwv+ARYrCjAxOaTCUT+Rbs5Q9+adW2DfRlL2d8tmFtJK5gUoYafJc3aIU53/wl2yN1s vqwX47/TDUjOea5rrk00Y+mH3HNGcUfaGB1xKETXQ4eTmVv2xrqYGKaMZ5m4gdVoO5Sr w+ygGOmtZ3/qWn2EV+htLOEMtAXXk8W1usuF72s+uSg80faKI5EJxutNyogC416RN7cW 6Xq/PYQiSbm9m2t4otCQ+134YBWDIsgETSoI89QHmtX8slfk1Egt9BC9QfP4qTQKHCmD /5FQ== X-Received: by 10.14.0.73 with SMTP id 49mr41137545eea.21.1362645796338; Thu, 07 Mar 2013 00:43:16 -0800 (PST) Received: from RoniE ([109.65.190.187]) by mx.google.com with ESMTPS id q5sm994386eeo.17.2013.03.07.00.43.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Mar 2013 00:43:15 -0800 (PST) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Thu, 7 Mar 2013 10:42:54 +0200 Message-ID: <05d601ce1b0f$c4399310$4cacb930$@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: AQIuk0EuC3Jd73dnk4xtAazIa2roxgJaeGs1l8YjTkA= Content-Language: en-us Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th 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, 07 Mar 2013 08:43:18 -0000 Hi, I am sorry I missed the meeting. On the SDP subject Jonathan, Qin and I submitted a document to MMUSIC http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-02 that tries to address also the CLUE concerns. It will also be discussed in the MMUSIC session as well as the one you mentioned http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 This topic was discussed in the MMUSIC interim meeting and it is important that the CLUE input should be addressed, please try to attend also the MMUSIC sessions (Tuesday and Friday (following AVText) Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 07 March, 2013 2:17 AM To: CLUE Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th Hi all, Here is a summary of Monday's meeting. Attendees: Mary Barnes, Mark Duckworth, Rob Hansen, Paul Kyzivat, Simon Pietro-Romano Notes: --------- The objective of the meeting was to review the plans and areas of focus for IETF-86. Framework: - with regards to Stephan's portion on the agenda, the expectation was to get an update on the rework and way forward. - we discussed the incorporation of Christian's suggestions (per the discussion of draft ) into the framework. Action: Mark to review and determine if/what changes are required for the framework - Mark noted that there are some issues in the tracker that should be closed. Action: chairs review emails and close related issues - Simultaneous sets: it appears the discussion on the list is converging. Mark: review and determine framework impacts. - Paul noted that Stephan had sent an email on FW issues, most of which really need to be resolved in solution documents Signaling/solution: - Note that Jonathan has produced a draft which was a result of the action item from IETF-85 for the RTCWEB/CLUE folks to work together for a model for RTP: http://www.ietf.org/id/draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt - In terms of the Signaling portion of the agenda on Tuesday, Paul will provide an overview/update on the current signaling solution document. That will lead into Rob's draft specifically analyzing SDP usage. Also, folks should read this document which identifies requirements some of which are applicable to CLUE: http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 It is on the MMUSIC WG agenda for discussion on Friday: https://datatracker.ietf.org/meeting/86/agenda/mmusic/ Regards, Mary. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Thu Mar 7 00:54:39 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 0794A21F8A3F for ; Thu, 7 Mar 2013 00:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dPBmoBFbh9N for ; Thu, 7 Mar 2013 00:54:37 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id AB29C21F8A4E for ; Thu, 7 Mar 2013 00:54:36 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so120071eek.15 for ; Thu, 07 Mar 2013 00:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=ZD6D0940ifsDtJ3SqQdK61uTZXTP6a+TPcLHBEqxekg=; b=vDrSn8DWuX+VPguvqBw27kaAtcGaSmybbAUyiIQPAnWWi0zchnJLdSa5t+S4V/sMYE CeHDMOwLZWhHr/W94f1a8BnwLXFPmtJ79FAbIRM0PQZVCs5wXDVwGj9WgiNvxotLVtNh bmhLc4ymEjmEjRnmp6xhkve6ZQ1lXDC3z8LDDGN+FND4P6qtSu1Z3xac2im0x13/iFCS E0Eyhy3F9K4ptJI0dQfq3se63mh4+vPNGrT50MCGAO9v5bsfvuZHMpsIomG/XKl1FaMm 1eR0BPuya6iuPkuSb+T8GGdTAzn8V+VHNvtZPEt2JYISlnJlWiyybXJZdr4NwZKfBu8V eXzQ== X-Received: by 10.14.215.193 with SMTP id e41mr1196191eep.32.1362646475777; Thu, 07 Mar 2013 00:54:35 -0800 (PST) Received: from RoniE ([109.65.190.187]) by mx.google.com with ESMTPS id 44sm1084208eek.5.2013.03.07.00.54.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Mar 2013 00:54:34 -0800 (PST) From: "Roni Even" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> Date: Thu, 7 Mar 2013 10:54:13 +0200 Message-ID: <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05D8_01CE1B22.1CCA2190" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfYWsXqe0hkOWzQ/TEJf74ED6BOJf3Xrbw Content-Language: en-us Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 08:54:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05D8_01CE1B22.1CCA2190 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Christer, This is a point I made in the past that for switched capture it may be good to know what is the policy, can be active speaker, time switch (round robin) or other methods. As for your second question advertisement is what can be sent, you probably meant that the configure message should allow to select a specific switch policy, I think that the configure can only ask for something that was advertised Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and provides the active speaker to a single screen entity. So, the content will change as the most active changes, but the capture provided by the MCU will be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement phase. Ie a single entity can indicate that it is able to receive a stream, where it want the content to be the "active speaker" role. Or? Regards, Christer ------=_NextPart_000_05D8_01CE1B22.1CCA2190 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

This is a point I made = in the past that for switched capture it may be good to know what is the = policy, can be active speaker, time switch (round robin) or other = methods.

 

As for your second = question advertisement is what can be sent, you probably meant that the = configure message should allow to select a specific switch policy, I = think that the configure can only ask for something that was = advertised

 

Roni =

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Christer Holmberg
Sent: 07 March, 2013 10:19 = AM
To: clue@ietf.org
Subject: [clue] Active speaker = a role?

 

Hi,

 

A couple of = questions related to the capture attribute draft.

 

Q1.

 

Assume you = have a MCU, which collects streams from multiple endpoints, and provides = the active speaker to a single screen entity. So, the content will = change as the most active changes, but the capture provided by the MCU = will be the same.

 

So, the = “role” of this capture would be “active = speaker”. Or?

 

 

Q2.

 

I assume = that capture attribute can also be used during the advertisement phase. = Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the “active speaker” role. = Or?

 

 

Regards,

 

Christer

 

------=_NextPart_000_05D8_01CE1B22.1CCA2190-- From christer.holmberg@ericsson.com Thu Mar 7 03:32: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 82A3021F8D10 for ; Thu, 7 Mar 2013 03:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tPRnjl4hWqc for ; Thu, 7 Mar 2013 03:32:26 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 81D6821F8CF6 for ; Thu, 7 Mar 2013 03:32:25 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-67-51387ac81bea Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 03.2D.19728.8CA78315; Thu, 7 Mar 2013 12:32:24 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 12:32:24 +0100 From: Christer Holmberg To: Roni Even , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkP//+iSA///ET0A= Date: Thu, 7 Mar 2013 11:32:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> In-Reply-To: <05d701ce1b11$59408e40$0bc1aac0$@gmail.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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B11498CESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje6JKotAgy1zNCz2n7rMbPG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyrj3pompYIdnRcPjC+wNjCscuhg5OCQETCRe Ty/oYuQEMsUkLtxbz9bFyMUhJHCIUaLj5X4mCGcRo8TDN31sIA1sAhYS3f+0QRpEBNwlmp4v ZAexhQW0JA7d/sgGEdeW6P/7iRnCtpL48PgvmM0ioCJxbckHZpAxvALeEpN+hoGEhQQqJV6v nQ82hhNo+o1//WA2I9A930+tYQKxmQXEJW49mc8EcaeAxJI955khbFGJl4//sULYihJXpy+H qs+XuDfhOZjNKyAocXLmE5YJjCKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIW X8DIvoqRPTcxMye93GgTIzBqDm75rbqD8c45kUOM0hwsSuK84a4XAoQE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUw1hh3/DDyjPh7Ludf1SsnnpzI7p7NpmWLkjg7JEMNu1beWbtCZZdz593M hiD96TocUxetcv7IvaY48mW3+YXop3Mav09kVS+6m2UzMYKB0chirnGx+KWTa97FX3uzIEos evfywMW7eXzqMv3nSmudOZL+T1mruMRh+sl1Qnt/LJrRwTtLwb1GiaU4I9FQi7moOBEA8lbe 9WgCAAA= Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 11:32:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B11498CESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >This is a point I made in the past that for switched capture it may be goo= d to know what is the policy, can be active speaker, time switch (round rob= in) or other methods. Correct. So, the question is whether that policy can be seen as a "role". There could also be "2nd recent speaker", "3rd recent speaker" etc, but ins= tead of defining a separate role for each of them, maybe we could have an a= ttribute value, e.g. "recent-speaker=3D2". This type of functionality is very important for devices with a limited num= ber of streams, screens etc - it non-telepresence rooms. >As for your second question advertisement is what can be sent, you probabl= y meant that the configure message should allow to select a specific switch= policy, I think that the configure can only ask for something that was adv= ertised Yes. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and = provides the active speaker to a single screen entity. So, the content will= change as the most active changes, but the capture provided by the MCU wil= l be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement p= hase. Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the "active speaker" role. Or? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B11498CESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

>This is a point I made in the past that for switched cap= ture it may be good to know what is the policy, can be active speaker, time= switch (round robin) or other methods.

 

Correct. So, the quest= ion is whether that policy can be seen as a “role”.<= /span>

 

There could also be &#= 8220;2nd recent speaker”, “3rd recent spe= aker” etc, but instead of defining a separate role for each of them, = maybe we could have an attribute value, e.g. “recent-speaker=3D2̶= 1;.

 

This type of functiona= lity is very important for devices with a limited number of streams, screen= s etc – it non-telepresence rooms.

 

>As for your second question advertisement is what can be= sent, you probably meant that the configure message should allow to select= a specific switch policy, I think that the configure can only ask for something that was advertised

 

Yes.=

 

Regards,

 

Christer

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 07 March, 2013 10:19 AM
To: clue@ietf.org
Subject: [clue] Active speaker a role?

 

Hi,

 

A couple of questions related to the capture attribu= te draft.

 

Q1.

 

Assume you have a MCU, which collects streams from m= ultiple endpoints, and provides the active speaker to a single screen entit= y. So, the content will change as the most active changes, but the capture = provided by the MCU will be the same.

 

So, the “role” of this capture would be = “active speaker”. Or?

 

 

Q2.

 

I assume that capture attribute can also be used dur= ing the advertisement phase. Ie a single entity can indicate that it is abl= e to receive a stream, where it want the content to be the “active sp= eaker” role. Or?

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B11498CESESSMB209ericsso_-- From ron.even.tlv@gmail.com Thu Mar 7 04:14:47 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 CFC5521F8D6E for ; Thu, 7 Mar 2013 04:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8celu1-1KLA for ; Thu, 7 Mar 2013 04:14:46 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id CB8AE21F8D8C for ; Thu, 7 Mar 2013 04:14:45 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so247090eek.13 for ; Thu, 07 Mar 2013 04:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=irGxgwbkcF8K3i/Uxt7jOOaitU6fjgT4lAkZO4m7R+Q=; b=K76AH57ub6PXSl14Fd91nJxliNt34Ecy4IK9O7+W1LCjLtQ95YvPHp4Kal52ExdCrL tqbA5zitVG06ZAfOoMu1gGxp+fQE70JEIkhdUTuuvmMIG4pbsJDmcvsqq2juXt2R8Mc2 lBGv4BmtiEi/wuc+PIjpkJ3VmjNladZsiFNnsl7uhvcysi2Z9pQ6TqvOaTecmrxVcaJs rGscfGHdVPno6CNKavY3noeYZWpgFAe+CNEYEaRpsUw9fMd5LO4LW6VgaP1NZ8xEgWWZ 92ZvyQu/BqC2U4fmzt2algG8InIuljgeGDs3zIaRAbbSgYQfaKUxTbu43EIQbT6Os4i4 5LxA== X-Received: by 10.14.207.200 with SMTP id n48mr6298329eeo.4.1362658484846; Thu, 07 Mar 2013 04:14:44 -0800 (PST) Received: from RoniE ([109.65.190.187]) by mx.google.com with ESMTPS id 44sm1933922eek.5.2013.03.07.04.14.42 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Mar 2013 04:14:43 -0800 (PST) From: "Roni Even" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> Date: Thu, 7 Mar 2013 14:14:21 +0200 Message-ID: <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0607_01CE1B3E.127A4B90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfYWsXqe0hkOWzQ/TEJf74ED6BOAIymSZDAreHrnSX0EWJkA== Content-Language: en-us Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 12:14:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0607_01CE1B3E.127A4B90 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Christer, I think that if we use CLUE to signal the active speaker, previous, Etc it will require many messages since the speakers change. The information who is speaking can be available from the CSRC or using the RTP header extension level attributes. RFC6465 provides the use case you discuss. Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 1:32 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >This is a point I made in the past that for switched capture it may be good to know what is the policy, can be active speaker, time switch (round robin) or other methods. Correct. So, the question is whether that policy can be seen as a "role". There could also be "2nd recent speaker", "3rd recent speaker" etc, but instead of defining a separate role for each of them, maybe we could have an attribute value, e.g. "recent-speaker=2". This type of functionality is very important for devices with a limited number of streams, screens etc - it non-telepresence rooms. >As for your second question advertisement is what can be sent, you probably meant that the configure message should allow to select a specific switch policy, I think that the configure can only ask for something that was advertised Yes. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and provides the active speaker to a single screen entity. So, the content will change as the most active changes, but the capture provided by the MCU will be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement phase. Ie a single entity can indicate that it is able to receive a stream, where it want the content to be the "active speaker" role. Or? Regards, Christer ------=_NextPart_000_0607_01CE1B3E.127A4B90 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Christer,

I think that if we use = CLUE to signal the active speaker, previous, Etc it will require many = messages since the speakers change. The information who is speaking can = be available from the CSRC or using the RTP header extension level = attributes. RFC6465 provides the use case you discuss. =

Roni

 

 

From:= = Christer Holmberg [mailto:christer.holmberg@ericsson.com] =
Sent: 07 March, 2013 1:32 PM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] Active speaker a = role?

 

Hi,

 

>This is a point I = made in the past that for switched capture it may be good to know what = is the policy, can be active speaker, time switch (round robin) or other = methods.

 

Correct. So, the = question is whether that policy can be seen as a = “role”.

 

There could also be = “2nd recent speaker”, “3rd = recent speaker” etc, but instead of defining a separate role for = each of them, maybe we could have an attribute value, e.g. = “recent-speaker=3D2”.

 

This type of = functionality is very important for devices with a limited number of = streams, screens etc – it non-telepresence = rooms.

 

>As for your second = question advertisement is what can be sent, you probably meant that the = configure message should allow to select a specific switch policy, I = think that the configure can only ask for something that was = advertised

 

Yes.

 

Regards,

 

Christer

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Christer Holmberg
Sent: 07 March, 2013 = 10:19 AM
To: clue@ietf.org
Subject: = [clue] Active speaker a role?

 

Hi,

 

A couple of = questions related to the capture attribute draft.

 

Q1.

 

Assume you = have a MCU, which collects streams from multiple endpoints, and provides = the active speaker to a single screen entity. So, the content will = change as the most active changes, but the capture provided by the MCU = will be the same.

 

So, the = “role” of this capture would be “active = speaker”. Or?

 

 

Q2.

 

I assume = that capture attribute can also be used during the advertisement phase. = Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the “active speaker” role. = Or?

 

 

Regards,

 

Christer

 

------=_NextPart_000_0607_01CE1B3E.127A4B90-- From christer.holmberg@ericsson.com Thu Mar 7 04:28:05 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 7D5A921F8AB4 for ; Thu, 7 Mar 2013 04:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me6xrXyPhz+D for ; Thu, 7 Mar 2013 04:28:03 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CBB8821F892A for ; Thu, 7 Mar 2013 04:28:02 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-5c-513887d1af56 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 58.B0.10459.1D788315; Thu, 7 Mar 2013 13:28:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 13:28:01 +0100 From: Christer Holmberg To: Roni Even , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkP//+iSA///ET0CAAHOcgP//7D3g Date: Thu, 7 Mar 2013 12:28:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> In-Reply-To: <060601ce1b2d$4ef06a20$ecd13e60$@gmail.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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B114A6DESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvje7FdotAg09PrSz2n7rMbPG3ndmB yWPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgyrh1ZjNTwfu0itPvVrE0MH6P7GLk4JAQMJHY /Ni5i5ETyBSTuHBvPVsXIxeHkMAhRok7fSfZQRJCAosYJfqeZ4HUswlYSHT/0wYJiwi4SzQ9 XwhWIiygJXHo9kc2iLi2RP/fT8wQtpvE079/mUFaWQRUJF50SoKEeQW8Jb5vvM0Eseolo8Sb V6sZQRKcQOM/bupiArEZge75fmoNmM0sIC5x68l8Jog7BSSW7DnPDGGLSrx8/I8VwlaUuDp9 OVR9vsSFnjuMEMsEJU7OfMIygVFkFpJRs5CUzUJSBhHXkViw+xMbhK0tsWzha2YY+8yBx0zI 4gsY2VcxsucmZuaklxtuYgRGzcEtv3V3MJ46J3KIUZqDRUmcN8z1QoCQQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGRufDx575x31l+bJI9LHQvdOhXz6/7Htrs6zeKOhFYeT3mzvZLxzMjWaV cVv0zurZtkPPmt8XsZvxfjc7sDiN03zCvgxGxjKptIUZOz/dk6/52ac1+zDjp3n3/QRffS7d VqP+b/YDf76PX2QO3nxgyHOVb9YuE4mqSVvnsbqe/pS9hid99cPF86uVWIozEg21mIuKEwHr 6D8MaAIAAA== Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 12:28:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B114A6DESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >I think that if we use CLUE to signal the active speaker, previous, Etc it= will require many messages since the speakers change. I am not sure I understand. The idea is to have a MCU capture, and e.g. a s= ingle stream, and the MCU switches the content based on who is active. Ther= e is no need to re-negotiate anything. Or, what messages do you refer to? >The information who is speaking can be available from the CSRC or using th= e RTP header extension level attributes. RFC6465 provides the use case you = discuss. I am not talking about WHO (as in whether it's Alice, Bob or Carol) is talk= ing, but that whoever is talking is provided from the MCU capture. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 1:32 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >This is a point I made in the past that for switched capture it may be goo= d to know what is the policy, can be active speaker, time switch (round rob= in) or other methods. Correct. So, the question is whether that policy can be seen as a "role". There could also be "2nd recent speaker", "3rd recent speaker" etc, but ins= tead of defining a separate role for each of them, maybe we could have an a= ttribute value, e.g. "recent-speaker=3D2". This type of functionality is very important for devices with a limited num= ber of streams, screens etc - it non-telepresence rooms. >As for your second question advertisement is what can be sent, you probabl= y meant that the configure message should allow to select a specific switch= policy, I think that the configure can only ask for something that was adv= ertised Yes. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and = provides the active speaker to a single screen entity. So, the content will= change as the most active changes, but the capture provided by the MCU wil= l be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement p= hase. Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the "active speaker" role. Or? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B114A6DESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

>I think that if we use CLUE to signal the active speaker= , previous, Etc it will require many messages since the speakers change.

 

I am not sure I unders= tand. The idea is to have a MCU capture, and e.g. a single stream, and the = MCU switches the content based on who is active. There is no need to re-neg= otiate anything. Or, what messages do you refer to?

 

>The information who is speaking can be available from th= e CSRC or using the RTP header extension level attributes. RFC6465 provides= the use case you discuss.

 

I am not talking about= WHO (as in whether it’s Alice, Bob or Carol) is talking, but that wh= oever is talking is provided from the MCU capture.

 

Regards,

 

Christer

 

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: 07 March, 2013 1:32 PM
To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role?

 

Hi,<= /p>

 

>This is a point I = made in the past that for switched capture it may be good to know what is t= he policy, can be active speaker, time switch (round robin) or other method= s.

 

Correct. So, the quest= ion is whether that policy can be seen as a “role”.<= /span>

 

There could also be &#= 8220;2nd recent speaker”, “3rd recent spe= aker” etc, but instead of defining a separate role for each of them, = maybe we could have an attribute value, e.g. “recent-speaker=3D2̶= 1;.

 

This type of functiona= lity is very important for devices with a limited number of streams, screen= s etc – it non-telepresence rooms.

 

>As for your second= question advertisement is what can be sent, you probably meant that the co= nfigure message should allow to select a specific switch policy, I think th= at the configure can only ask for something that was advertised

 

Yes.=

 

Regards,

 

Christer

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 07 March, 2013 10:19 AM
To: clue@ietf.org
Subject: [clue] Active speaker a role?

 

Hi,

 

A couple of questions related to the capture attribu= te draft.

 

Q1.

 

Assume you have a MCU, which collects streams from m= ultiple endpoints, and provides the active speaker to a single screen entit= y. So, the content will change as the most active changes, but the capture = provided by the MCU will be the same.

 

So, the “role” of this capture would be = “active speaker”. Or?

 

 

Q2.

 

I assume that capture attribute can also be used dur= ing the advertisement phase. Ie a single entity can indicate that it is abl= e to receive a stream, where it want the content to be the “active sp= eaker” role. Or?

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B114A6DESESSMB209ericsso_-- From ron.even.tlv@gmail.com Thu Mar 7 04:45: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 EB73B21F85CE for ; Thu, 7 Mar 2013 04:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izvg3UZAVenn for ; Thu, 7 Mar 2013 04:45:42 -0800 (PST) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by ietfa.amsl.com (Postfix) with ESMTP id A92AE21F85B1 for ; Thu, 7 Mar 2013 04:45:41 -0800 (PST) Received: by mail-ee0-f41.google.com with SMTP id c13so268658eek.0 for ; Thu, 07 Mar 2013 04:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=AbrKKiP0HdL2s6RGU36uxyJxiKhQEWFwkmVK5vIht+0=; b=TCEvRraceFU5aDQefSvrPCTFRg2f/73R0qWButTiOxGcM/iC/uqsXoTXjko9r2KBtB hQymKR+ZWe+V33CiYIhph5mm5y3h8rFLlkoF50Rt2Lnlb/pew9/x4KoHIeF+l42HAVWc /Fu7pkxY466pzz1hP4btZMmo8mLRjqkAQdeJKGY+gYi1U0a5nxiPPKKvCWvehGOlO0ec HWtlw/zjkA9svPXyQQ2OIO9pXsRb0wx3BXlh6zFfE+CxAzo9O8V3QfzViy9KIVblYO1B Cb7UJ0jTlzflDBPpxfue5Jdvd5yDYqHYAfKht0RYU9WV4cdkjTET3nd6jCGEfK7+dkSF l5AQ== X-Received: by 10.15.45.201 with SMTP id b49mr55498770eew.9.1362660340714; Thu, 07 Mar 2013 04:45:40 -0800 (PST) Received: from RoniE ([109.65.190.187]) by mx.google.com with ESMTPS id r4sm2031578eeo.12.2013.03.07.04.45.37 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Mar 2013 04:45:39 -0800 (PST) From: "Roni Even" To: "'Christian Groves'" , References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> In-Reply-To: <51381D05.3090101@nteczone.com> Date: Thu, 7 Mar 2013 14:45:18 +0200 Message-ID: <061401ce1b31$a124bd10$e36e3730$@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: AQGCouypXztAekyzN8hYSZDRJBYPGgLIbP+bAqaeF2UCXGcyowIH6LAhmOKBIhA= Content-Language: en-us Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 12:45:43 -0000 Hi, I agree about the single media type. Still we can use capture scene entry as a shorthand in the simultaneous set. A Scene has capture scene entries where, as far as I understand, the entries are not simultaneous, you can choose one or part of one, so you cannot have a whole scene as a simultaneous set. Capture scene entry has media of same type. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves Sent: 07 March, 2013 6:52 AM To: clue@ietf.org Subject: Re: [clue] comments to framework 09 - simultaneous sets Hello, I agree with Mark's original conclusions. I also tend to agree with item 2 below. Regards, Christian On 7/03/2013 5:58 AM, Duckworth, Mark wrote: > Hi Paul, > > I was assuming your item 2 is what we would do. But it could be open for discussion. > >> 2) keep the current assumption that a simultaneous set applies to >> only one medium. If a set contains references to CSs, factor those by >> media type, and create multiple sets - one for each medium. > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Wednesday, March 06, 2013 10:13 AM >> To: clue@ietf.org >> Subject: Re: [clue] comments to framework 09 - simultaneous sets >> >> Mark, >> >> I agree with all you say below. >> >> But this does lead to another related issue that needs some consideration. >> Until now I think we have said that a single simultaneous set should >> mention only a single medium - voice or video. When we permit it to >> reference a complete scene it will have entries for different kinds >> of media. So what does that mean? >> >> Having simultaneous sets only reference a single medium implies that >> simultaneity across media types is implicit. I wonder if that is really true. >> >> Some possible resolutions to this: >> >> 1) keep the current assumption that a simultaneous set applies to >> only one medium, and to preserve that forbid the inclusion of a >> complete CS if it contains more than one type of medium. >> >> 2) keep the current assumption that a simultaneous set applies to >> only one medium. If a set contains references to CSs, factor those by >> media type, and create multiple sets - one for each medium. >> >> 3) forbid references to CSs in simultaneous sets >> >> 4) change the definition of simultaneous sets so that they explicitly >> define permitted simultaneity among multiple media types. >> >> I haven't decided my own preference among the above. >> >> Thanks, >> Paul >> >> >> >> On 3/6/13 10:32 PM, Duckworth, Mark wrote: >>> I will try to summarize what I think the conclusions are from this thread. >>> >>> Point 1 - we generally agree simultaneity restrictions are not just >>> about >> physical constraints, there are other reasons. >>> Point 2 - we should remove the bit about "may not make sense to do so". >>> >>> Point 3 - we generally agree it would be good to allow expressing >> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set >> Entries, as well as Media Captures that the Provider can provide simultaneously. >>> Point 4 - we generally agree (again) we do not want to define other >>> ways of >> expressing Simultaneous Transmission Sets, such as by mutual >> exclusion or with logical operators. >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>> Behalf Of Roberta Presta >>>> Sent: Wednesday, February 27, 2013 1:47 PM >>>> To: clue@ietf.org >>>> Subject: [clue] comments to framework 09 - simultaneous sets >>>> >>>> Hi all, >>>> >>>> sorry for boring you always with the same things :) >>>> >>>> When I read Section 6.3 "Simultaneous Transmission Set Constraint", >>>> I noticed a couple of things: >>>> >>>> 1) the only motivation that has been provided to justify the >>>> definition of simultaneous sets is the fact that captures generated >>>> from the same device cannot be sent simultaneously. However, there >>>> can be other motivations behind the need of expressing simultaneity >>>> constraints (leaving resource constraints handled by encoding >>>> groups and other stuff such as max- >>>> encoding- and so on). >>>> Citing Andy Pepperel in >>>> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, >>>> simultaneous sets can be used by MCUs that might not want to be >>>> obliged to provide some capture simultaneously, in order to avoid >> overloading. >>>> I think that these other motivations should be explicitely >>>> mentioned in the framework document to explain that simultaneity >>>> limitations may not be due only to physical constraints. >>>> >>>> 2) Copying from the document: "Simultaneous transmission sets are >>>> expressed as sets of the Media Captures that could physically be >>>> transmitted at the same time (though it may not make sense to do so). " >>>> Does it mean that even if there is a large set of captures able to >>>> be sent simultaneously, it may not make sense, from the consumer's >>>> perspective, to receive them all together? Maybe rewording is >>>> needed >> here. >>>> 3) Again, on the design (and definition) of the simultaneous sets. >>>> >>>> Simultaneous sets, as defined in the framework, are *all* the >>>> groups of >>>> *captures* that can be sent together. >>>> The consumer presumably has to check if the set of captures he >>>> wants is fully >>>> *included* in almost one of the listed ones. >>>> If not, he has to re-structure the configure to fit simultaneity >>>> constraints expressed by the provider. >>>> (Is that the expected behavior of the consumer?) >>>> >>>> I was thinking that each set can be expressed also in terms of >>>> capture scene entries, or capture scene as a whole, for example: >>>> 1) CSE1, CSE2, CS3, VC1, CS5 >>>> 2) CSE1, CSE4, CS3, VC1, CS5 >>>> .... >>>> Where CSE* identifies a capture scene entry, and CS* identifies a >>>> capture scene. >>>> That can allow to make simultaneous sets more synthetic by >>>> exploiting the capture aggregates the framework envisions. It can >>>> be particularly useful to MCUs that want to offer just subsets of >>>> the complete list of capture scenes they receive from multiple contributors. >>>> >>>> >>>> 4) Some further reasoning. >>>> >>>> In some cases it can be more efficient to express only mutual >>>> exclusion constraints. >>>> We could discuss about envisioning a section of information named >>>> "simultaneity constraints" that can include a list of simultaneous >>>> sets and a list of mutual exclusion conditions to be checked on the >> consumer's side. >>>> For example, if a media provider offers many captures, and has only >>>> 4 mutual exclusion conditions, instead of listing all the possible >>>> simultaneous sets, he can just provide the 4 mutual exclusion >>>> conditions >> to the consumer. >>>> Another alternative is also Christer Holmberg's proposal in >>>> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, >>>> where simultaneity constraints are logical conditions that the >>>> consumer has to verify before issuing a configure to the provider. >>>> The example was: >>>> >>>> "(CSE-X AND CSE-Y) OR CSE-Z. >>>> >>>> This means that the provider can provide CSE-X and CSE Y (and all >>>> captures associated with CSE-X and CSE-Y) simultaneously, or that >>>> the provider can provide CSE-Z (and all captures associated with CSE-Z)." >>>> >>>> Do you think we should stuck on the framework solution or also >>>> consider the aforementioned alternatives? >>>> I promise I stop thinking about it! >>>> >>>> RP >>>> >>>> -- >>>> Roberta Presta, Ph.D. Student >>>> Dipartimento di Ingegneria Elettrica e delle Tecnologie >>>> dell'Informazione >>>> (DIETI) Universita' degli Studi di Napoli "Federico II" >>>> Via Claudio 21 -- 80125 Napoli (Italy) >>>> Phone: +390817683821 - Fax: +390817683816 >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Thu Mar 7 04:49: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 0102421F8992 for ; Thu, 7 Mar 2013 04:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 seGUb4ER4MSv for ; Thu, 7 Mar 2013 04:49:35 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6395821F8667 for ; Thu, 7 Mar 2013 04:49:34 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-d6-51388cdda7c5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 97.D3.10459.DDC88315; Thu, 7 Mar 2013 13:49:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 13:49:33 +0100 From: Christer Holmberg To: Roni Even , 'Christian Groves' , "clue@ietf.org" Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiYs+6AgAALTQCAAD7qAIAApfyAgACEJACAABFUkA== Date: Thu, 7 Mar 2013 12:49:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> In-Reply-To: <061401ce1b31$a124bd10$e36e3730$@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje7dHotAg6Y1KhZf3jeyWOw/dZnZ 4m87swOzx85Zd9k9liz5yeSx4vxMlgDmKC6blNSczLLUIn27BK6MqY+1Ci77VJxddoGlgfG5 XRcjJ4eEgInE68b1rBC2mMSFe+vZuhi5OIQEDjFKzJwzhwXCWcQosXT9NKAMBwebgIVE9z9t kAYRgVqJjv0v2UBsYQEHiZZfU1gh4o4Sq1bNY4GwwyS+rZ3HDmKzCKhIbHnRxQxi8wp4Sxy5 2MYMMX8+k8SEl//AGjiB5l9o3M0IYjMCXfT91BomEJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5 +B/UB4oSV6cvh6rXkViw+xMbhK0tsWzha6jFghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sq RvbcxMyc9HLDTYzA6Di45bfuDsZT50QOMUpzsCiJ84a5XggQEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwBhm4J3Hu8mEucWx12/qCxmmQ9Yvn5oZnyiY1n7uTG7toTl+ni+uPzvvwF9tYfYj /Tvf7r2valyNbRddf34nchW/cNPGhd0PK/d0NDcqM04tMnJ34ObPMCxRkFix6v653QWT2ut9 vnXEvowMTNTOfyIsHn7w7N7r6W0iux8eCyq28Oqtlu3ar8RSnJFoqMVcVJwIAFfJ8cJcAgAA Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 12:49:36 -0000 Hi, Do we assume there is a one-to-one mapping between video and audio captures= ? For example, assume one video capture has the role "manager". That doesn't mean that there will be an audio capture with the same role, b= ecause the audio capture may cover a bigger area, including many persons. So, if I show the manager on my screen, how do I know which audio capture t= o choose? Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 7. maaliskuuta 2013 14:45 To: 'Christian Groves'; clue@ietf.org Subject: Re: [clue] comments to framework 09 - simultaneous sets Hi, I agree about the single media type. Still we can use capture scene entry as a shorthand in the simultaneous set= . A Scene has capture scene entries where, as far as I understand, the entrie= s are not simultaneous, you can choose one or part of one, so you cannot ha= ve a whole scene as a simultaneous set. Capture scene entry has media of same type. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= istian Groves Sent: 07 March, 2013 6:52 AM To: clue@ietf.org Subject: Re: [clue] comments to framework 09 - simultaneous sets Hello, I agree with Mark's original conclusions. I also tend to agree with item 2 below. Regards, Christian On 7/03/2013 5:58 AM, Duckworth, Mark wrote: > Hi Paul, > > I was assuming your item 2 is what we would do. But it could be open=20 > for discussion. > >> 2) keep the current assumption that a simultaneous set applies to=20 >> only one medium. If a set contains references to CSs, factor those by=20 >> media type, and create multiple sets - one for each medium. > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 >> Of Paul Kyzivat >> Sent: Wednesday, March 06, 2013 10:13 AM >> To: clue@ietf.org >> Subject: Re: [clue] comments to framework 09 - simultaneous sets >> >> Mark, >> >> I agree with all you say below. >> >> But this does lead to another related issue that needs some consideration. >> Until now I think we have said that a single simultaneous set should=20 >> mention only a single medium - voice or video. When we permit it to=20 >> reference a complete scene it will have entries for different kinds=20 >> of media. So what does that mean? >> >> Having simultaneous sets only reference a single medium implies that=20 >> simultaneity across media types is implicit. I wonder if that is=20 >> really true. >> >> Some possible resolutions to this: >> >> 1) keep the current assumption that a simultaneous set applies to=20 >> only one medium, and to preserve that forbid the inclusion of a=20 >> complete CS if it contains more than one type of medium. >> >> 2) keep the current assumption that a simultaneous set applies to=20 >> only one medium. If a set contains references to CSs, factor those by=20 >> media type, and create multiple sets - one for each medium. >> >> 3) forbid references to CSs in simultaneous sets >> >> 4) change the definition of simultaneous sets so that they explicitly=20 >> define permitted simultaneity among multiple media types. >> >> I haven't decided my own preference among the above. >> >> Thanks, >> Paul >> >> >> >> On 3/6/13 10:32 PM, Duckworth, Mark wrote: >>> I will try to summarize what I think the conclusions are from this thread. >>> >>> Point 1 - we generally agree simultaneity restrictions are not just=20 >>> about >> physical constraints, there are other reasons. >>> Point 2 - we should remove the bit about "may not make sense to do so". >>> >>> Point 3 - we generally agree it would be good to allow expressing >> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set=20 >> Entries, as well as Media Captures that the Provider can provide simultaneously. >>> Point 4 - we generally agree (again) we do not want to define other=20 >>> ways of >> expressing Simultaneous Transmission Sets, such as by mutual=20 >> exclusion or with logical operators. >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 >>>> Behalf Of Roberta Presta >>>> Sent: Wednesday, February 27, 2013 1:47 PM >>>> To: clue@ietf.org >>>> Subject: [clue] comments to framework 09 - simultaneous sets >>>> >>>> Hi all, >>>> >>>> sorry for boring you always with the same things :) >>>> >>>> When I read Section 6.3 "Simultaneous Transmission Set Constraint",=20 >>>> I noticed a couple of things: >>>> >>>> 1) the only motivation that has been provided to justify the=20 >>>> definition of simultaneous sets is the fact that captures generated=20 >>>> from the same device cannot be sent simultaneously. However, there=20 >>>> can be other motivations behind the need of expressing simultaneity=20 >>>> constraints (leaving resource constraints handled by encoding=20 >>>> groups and other stuff such as max- >>>> encoding- and so on). >>>> Citing Andy Pepperel in >>>> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, >>>> simultaneous sets can be used by MCUs that might not want to be=20 >>>> obliged to provide some capture simultaneously, in order to avoid >> overloading. >>>> I think that these other motivations should be explicitely=20 >>>> mentioned in the framework document to explain that simultaneity=20 >>>> limitations may not be due only to physical constraints. >>>> >>>> 2) Copying from the document: "Simultaneous transmission sets are=20 >>>> expressed as sets of the Media Captures that could physically be=20 >>>> transmitted at the same time (though it may not make sense to do so). = " >>>> Does it mean that even if there is a large set of captures able to=20 >>>> be sent simultaneously, it may not make sense, from the consumer's=20 >>>> perspective, to receive them all together? Maybe rewording is=20 >>>> needed >> here. >>>> 3) Again, on the design (and definition) of the simultaneous sets. >>>> >>>> Simultaneous sets, as defined in the framework, are *all* the=20 >>>> groups of >>>> *captures* that can be sent together. >>>> The consumer presumably has to check if the set of captures he=20 >>>> wants is fully >>>> *included* in almost one of the listed ones. >>>> If not, he has to re-structure the configure to fit simultaneity=20 >>>> constraints expressed by the provider. >>>> (Is that the expected behavior of the consumer?) >>>> >>>> I was thinking that each set can be expressed also in terms of=20 >>>> capture scene entries, or capture scene as a whole, for example: >>>> 1) CSE1, CSE2, CS3, VC1, CS5 >>>> 2) CSE1, CSE4, CS3, VC1, CS5 >>>> .... >>>> Where CSE* identifies a capture scene entry, and CS* identifies a=20 >>>> capture scene. >>>> That can allow to make simultaneous sets more synthetic by=20 >>>> exploiting the capture aggregates the framework envisions. It can=20 >>>> be particularly useful to MCUs that want to offer just subsets of=20 >>>> the complete list of capture scenes they receive from multiple contributors. >>>> >>>> >>>> 4) Some further reasoning. >>>> >>>> In some cases it can be more efficient to express only mutual=20 >>>> exclusion constraints. >>>> We could discuss about envisioning a section of information named=20 >>>> "simultaneity constraints" that can include a list of simultaneous=20 >>>> sets and a list of mutual exclusion conditions to be checked on the >> consumer's side. >>>> For example, if a media provider offers many captures, and has only >>>> 4 mutual exclusion conditions, instead of listing all the possible=20 >>>> simultaneous sets, he can just provide the 4 mutual exclusion=20 >>>> conditions >> to the consumer. >>>> Another alternative is also Christer Holmberg's proposal in=20 >>>> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, >>>> where simultaneity constraints are logical conditions that the=20 >>>> consumer has to verify before issuing a configure to the provider. >>>> The example was: >>>> >>>> "(CSE-X AND CSE-Y) OR CSE-Z. >>>> >>>> This means that the provider can provide CSE-X and CSE Y (and all=20 >>>> captures associated with CSE-X and CSE-Y) simultaneously, or that=20 >>>> the provider can provide CSE-Z (and all captures associated with CSE-Z)." >>>> >>>> Do you think we should stuck on the framework solution or also=20 >>>> consider the aforementioned alternatives? >>>> I promise I stop thinking about it! >>>> >>>> RP >>>> >>>> -- >>>> Roberta Presta, Ph.D. Student >>>> Dipartimento di Ingegneria Elettrica e delle Tecnologie=20 >>>> dell'Informazione >>>> (DIETI) Universita' degli Studi di Napoli "Federico II" >>>> Via Claudio 21 -- 80125 Napoli (Italy) >>>> Phone: +390817683821 - Fax: +390817683816 >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Thu Mar 7 04:52: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 133AD21F8AB2 for ; Thu, 7 Mar 2013 04:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM7pHCQazf6Z for ; Thu, 7 Mar 2013 04:52:25 -0800 (PST) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by ietfa.amsl.com (Postfix) with ESMTP id 847B721F8C59 for ; Thu, 7 Mar 2013 04:52:24 -0800 (PST) Received: by mail-ee0-f49.google.com with SMTP id d41so257651eek.36 for ; Thu, 07 Mar 2013 04:52:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=QZsYNWMoyOPoRfahx1To1/nh2xy6tsbWQxMODRjU4wA=; b=vByYPhcQaCL6PYx0SKPTXjEXu6M9UvqFWygI4x4vOLQAGXKKbK2fGbIFVFESTm9p6a n+OXQOgoYufvLWVYalka0DXbPwY7wjh+9PqODstiUduWLUu7IkRRNfrqqTjcQa0qGZkG RpNGOm+CUFcnG1/jhJhqsVy3/5VqRkYW75o/M7FOP7USRHqY1pKwYnDWnShngVLx1q2v +0vGb116Xhszj0hGEr+e9oeeg9iMoLVdKC3edQkDyNDfUXcEkiP0JVQyB0gpgwA0+yXt oZAEPQOGbw/ONJ8RitebXaGF2jOfYVccK+lsVPUF9hQ6/EVj5sREC03CEBnrJNkRhAuY BvmQ== X-Received: by 10.14.173.196 with SMTP id v44mr92682339eel.29.1362660743633; Thu, 07 Mar 2013 04:52:23 -0800 (PST) Received: from RoniE ([109.65.190.187]) by mx.google.com with ESMTPS id q5sm2047183eeo.17.2013.03.07.04.52.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Mar 2013 04:52:22 -0800 (PST) From: "Roni Even" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> Date: Thu, 7 Mar 2013 14:52:01 +0200 Message-ID: <061501ce1b32$91608660$b4219320$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0616_01CE1B43.54EA8EE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfYWsXqe0hkOWzQ/TEJf74ED6BOAIymSZDAreHrnQDEGPXBgKcL5Zfl6LrgqA= Content-Language: en-us Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 12:52:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0616_01CE1B43.54EA8EE0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I will try to understand. What you are saying that we will have, for example, three media captures, "current speaker","recent-1" and "recent-2". This will be used for MCU that does voice activation video switching but sends more than one RTP stream to each receiver. Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 2:28 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >I think that if we use CLUE to signal the active speaker, previous, Etc it will require many messages since the speakers change. I am not sure I understand. The idea is to have a MCU capture, and e.g. a single stream, and the MCU switches the content based on who is active. There is no need to re-negotiate anything. Or, what messages do you refer to? >The information who is speaking can be available from the CSRC or using the RTP header extension level attributes. RFC6465 provides the use case you discuss. I am not talking about WHO (as in whether it's Alice, Bob or Carol) is talking, but that whoever is talking is provided from the MCU capture. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 1:32 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >This is a point I made in the past that for switched capture it may be good to know what is the policy, can be active speaker, time switch (round robin) or other methods. Correct. So, the question is whether that policy can be seen as a "role". There could also be "2nd recent speaker", "3rd recent speaker" etc, but instead of defining a separate role for each of them, maybe we could have an attribute value, e.g. "recent-speaker=2". This type of functionality is very important for devices with a limited number of streams, screens etc - it non-telepresence rooms. >As for your second question advertisement is what can be sent, you probably meant that the configure message should allow to select a specific switch policy, I think that the configure can only ask for something that was advertised Yes. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and provides the active speaker to a single screen entity. So, the content will change as the most active changes, but the capture provided by the MCU will be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement phase. Ie a single entity can indicate that it is able to receive a stream, where it want the content to be the "active speaker" role. Or? Regards, Christer ------=_NextPart_000_0616_01CE1B43.54EA8EE0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

I will try to = understand. What you are saying that we will have, for example, three = media captures, “current speaker”,”recent-1” and = “recent-2”. This will be used for MCU that does voice = activation video switching but sends more than one RTP stream to each = receiver.

Roni

 

From:= = Christer Holmberg [mailto:christer.holmberg@ericsson.com] =
Sent: 07 March, 2013 2:28 PM
To: Roni Even; = clue@ietf.org
Subject: RE: [clue] Active speaker a = role?

 

Hi,

 

>I think that if we = use CLUE to signal the active speaker, previous, Etc it will require = many messages since the speakers change.

 

I am not sure I = understand. The idea is to have a MCU capture, and e.g. a single stream, = and the MCU switches the content based on who is active. There is no = need to re-negotiate anything. Or, what messages do you refer = to?

 

>The information who = is speaking can be available from the CSRC or using the RTP header = extension level attributes. RFC6465 provides the use case you discuss. =

 

I am not talking about = WHO (as in whether it’s Alice, Bob or Carol) is talking, but that = whoever is talking is provided from the MCU = capture.

 

Regards,

 

Christer

 

 

From:= = Christer Holmberg [mailto:christer.holmberg@e= ricsson.com]
Sent: 07 March, 2013 1:32 PM
To: = Roni Even; clue@ietf.org
Subject: RE: = [clue] Active speaker a role?

 

Hi,

 

>This is a point I = made in the past that for switched capture it may be good to know what = is the policy, can be active speaker, time switch (round robin) or other = methods.

 

Correct. So, the = question is whether that policy can be seen as a = “role”.

 

There could also be = “2nd recent speaker”, “3rd = recent speaker” etc, but instead of defining a separate role for = each of them, maybe we could have an attribute value, e.g. = “recent-speaker=3D2”.

 

This type of = functionality is very important for devices with a limited number of = streams, screens etc – it non-telepresence = rooms.

 

>As for your second = question advertisement is what can be sent, you probably meant that the = configure message should allow to select a specific switch policy, I = think that the configure can only ask for something that was = advertised

 

Yes.

 

Regards,

 

Christer

 

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] = On Behalf Of Christer Holmberg
Sent: 07 March, 2013 = 10:19 AM
To: clue@ietf.org
Subject: = [clue] Active speaker a role?

 

Hi,

 

A couple of = questions related to the capture attribute draft.

 

Q1.

 

Assume you = have a MCU, which collects streams from multiple endpoints, and provides = the active speaker to a single screen entity. So, the content will = change as the most active changes, but the capture provided by the MCU = will be the same.

 

So, the = “role” of this capture would be “active = speaker”. Or?

 

 

Q2.

 

I assume = that capture attribute can also be used during the advertisement phase. = Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the “active speaker” role. = Or?

 

 

Regards,

 

Christer

 

------=_NextPart_000_0616_01CE1B43.54EA8EE0-- From christer.holmberg@ericsson.com Thu Mar 7 05:14: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 671C521F8C99 for ; Thu, 7 Mar 2013 05:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uihB3MRYwAN2 for ; Thu, 7 Mar 2013 05:14:13 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2921F8C4E for ; Thu, 7 Mar 2013 05:14:11 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-6f-513892a21be1 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A3.5D.19728.2A298315; Thu, 7 Mar 2013 14:14:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 14:14:10 +0100 From: Christer Holmberg To: Roni Even , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkP//+iSA///ET0CAAHOcgP//7D3ggAAeSYD//+nn8A== Date: Thu, 7 Mar 2013 13:14:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B114B6A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> <061501ce1b32$91608660$b4219320$@gmail.com> In-Reply-To: <061501ce1b32$91608660$b4219320$@gmail.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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B114B6AESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje7iSRaBBhs+MlvsP3WZ2eJvO7MD k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlXF98RXWgkmdjBUnf8k1MP4r72Lk4JAQMJHY /lu6i5ETyBSTuHBvPVsXIxeHkMAhRomZ2zczQTiLGCW6j/9lBGlgE7CQ6P6nDdIgIuAu0fR8 ITuILSygJXHo9kc2iLi2RP/fT8wQdpjEva3vweIsAioS/552s4LYvALeEo0dv5gh5t9kklj2 5CNYghNo/r/LEEWMQBd9P7WGCcRmFhCXuPVkPhPEpQISS/acZ4awRSVePv7HCmErSlydvhyq Pl/i2N5+dohlghInZz5hmcAoMgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEF jOyrGNlzEzNz0suNNjECI+fglt+qOxjvnBM5xCjNwaIkzhvueiFASCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA2NBxoITyqfrZ0788vWZpKzqhfULa3YmXDT0zHt/xH9yt8ZERou/V/xdV9Q8 VX7OmDtngtzeLJ8AMaNN//QCe3asFpbmPLVmg8NvjxdZV4VmR/VVhXFYPgl+F5u8g6WPd8er 6c018zd9ud2puubvetXmlc7O0avXvXYNKj8+5bfWIfuSwiazfGMlluKMREMt5qLiRAAg7Q3K agIAAA== Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 13:14:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B114B6AESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The MCU will advertise, to me, that it can provide three media captures (as= in your example). The MCU will then receive media from all other participa= nts, do voice activation, and forward the media streams with the "current s= peaker", "recenve-1" etc to me. How the other endpoints provide their media to the MCU, and what roles are = used, is a separate story. Regards, Christer From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 7. maaliskuuta 2013 14:52 To: Christer Holmberg; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, I will try to understand. What you are saying that we will have, for exampl= e, three media captures, "current speaker","recent-1" and "recent-2". This = will be used for MCU that does voice activation video switching but sends m= ore than one RTP stream to each receiver. Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 2:28 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >I think that if we use CLUE to signal the active speaker, previous, Etc it= will require many messages since the speakers change. I am not sure I understand. The idea is to have a MCU capture, and e.g. a s= ingle stream, and the MCU switches the content based on who is active. Ther= e is no need to re-negotiate anything. Or, what messages do you refer to? >The information who is speaking can be available from the CSRC or using th= e RTP header extension level attributes. RFC6465 provides the use case you = discuss. I am not talking about WHO (as in whether it's Alice, Bob or Carol) is talk= ing, but that whoever is talking is provided from the MCU capture. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 1:32 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >This is a point I made in the past that for switched capture it may be goo= d to know what is the policy, can be active speaker, time switch (round rob= in) or other methods. Correct. So, the question is whether that policy can be seen as a "role". There could also be "2nd recent speaker", "3rd recent speaker" etc, but ins= tead of defining a separate role for each of them, maybe we could have an a= ttribute value, e.g. "recent-speaker=3D2". This type of functionality is very important for devices with a limited num= ber of streams, screens etc - it non-telepresence rooms. >As for your second question advertisement is what can be sent, you probabl= y meant that the configure message should allow to select a specific switch= policy, I think that the configure can only ask for something that was adv= ertised Yes. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and = provides the active speaker to a single screen entity. So, the content will= change as the most active changes, but the capture provided by the MCU wil= l be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement p= hase. Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the "active speaker" role. Or? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B114B6AESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

The MCU will advertise= , to me, that it can provide three media captures (as in your example). The= MCU will then receive media from all other participants, do voice activati= on, and forward the media streams with the “current speaker”, “recenve-1” etc to me.=

 

How the other endpoint= s provide their media to the MCU, and what roles are used, is a separate st= ory.

 

Regards,

 

Christer

 

 

From: Roni Eve= n [mailto:ron.even.tlv@gmail.com]
Sent: 7. maaliskuuta 2013 14:52
To: Christer Holmberg; clue@ietf.org
Subject: RE: [clue] Active speaker a role?

 

Hi,<= /p>

I will try to understa= nd. What you are saying that we will have, for example, three media capture= s, “current speaker”,”recent-1” and “recent-2= ”. This will be used for MCU that does voice activation video switchi= ng but sends more than one RTP stream to each receiver.

Roni=

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: 07 March, 2013 2:28 PM
To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role?

 

Hi,<= /p>

 

>I think that if we= use CLUE to signal the active speaker, previous, Etc it will require many = messages since the speakers change.

 

I am not sure I unders= tand. The idea is to have a MCU capture, and e.g. a single stream, and the = MCU switches the content based on who is active. There is no need to re-neg= otiate anything. Or, what messages do you refer to?

 

>The information wh= o is speaking can be available from the CSRC or using the RTP header extens= ion level attributes. RFC6465 provides the use case you discuss.

 

I am not talking about= WHO (as in whether it’s Alice, Bob or Carol) is talking, but that wh= oever is talking is provided from the MCU capture.

 

Regards,

 

Christer

 

 

From: Christer= Holmberg [mailto:christe= r.holmberg@ericsson.com]
Sent: 07 March, 2013 1:32 PM
To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role?

 

Hi,<= /p>

 

>This is a point I = made in the past that for switched capture it may be good to know what is t= he policy, can be active speaker, time switch (round robin) or other method= s.

 

Correct. So, the quest= ion is whether that policy can be seen as a “role”.<= /span>

 

There could also be &#= 8220;2nd recent speaker”, “3rd recent spe= aker” etc, but instead of defining a separate role for each of them, = maybe we could have an attribute value, e.g. “recent-speaker=3D2̶= 1;.

 

This type of functiona= lity is very important for devices with a limited number of streams, screen= s etc – it non-telepresence rooms.

 

>As for your second= question advertisement is what can be sent, you probably meant that the co= nfigure message should allow to select a specific switch policy, I think th= at the configure can only ask for something that was advertised

 

Yes.=

 

Regards,

 

Christer

 

 

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 07 March, 2013 10:19 AM
To: clue@ietf.org
Subject: [clue] Active speaker a role?

 

Hi,

 

A couple of questions related to the capture attribu= te draft.

 

Q1.

 

Assume you have a MCU, which collects streams from m= ultiple endpoints, and provides the active speaker to a single screen entit= y. So, the content will change as the most active changes, but the capture = provided by the MCU will be the same.

 

So, the “role” of this capture would be = “active speaker”. Or?

 

 

Q2.

 

I assume that capture attribute can also be used dur= ing the advertisement phase. Ie a single entity can indicate that it is abl= e to receive a stream, where it want the content to be the “active sp= eaker” role. Or?

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B114B6AESESSMB209ericsso_-- From pkyzivat@alum.mit.edu Thu Mar 7 06:50: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 1166E21F8917 for ; Thu, 7 Mar 2013 06:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[AWL=0.252, 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 5mZAsfkz0x8V for ; Thu, 7 Mar 2013 06:50:54 -0800 (PST) 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 37BA021F859A for ; Thu, 7 Mar 2013 06:50:54 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id 8c931l0041ei1Bg59eqtGl; Thu, 07 Mar 2013 14:50:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 8eqt1l00L3ZTu2S3keqt2g; Thu, 07 Mar 2013 14:50:53 +0000 Message-ID: <5138A94D.9020703@alum.mit.edu> Date: Thu, 07 Mar 2013 22:50:53 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512A9240.3040800@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539E39@CRPMBOXPRD01.polycom.com> <5136224C.4020000@alum.mit.edu> <513807AE.1050303@nteczone.com> In-Reply-To: <513807AE.1050303@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=1362667853; bh=zwf96DFKiTZ5vfh7ZnkMQDWgoRWBxiqyrvRtQUxAF7E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=J2VCG+KOXjq6p1cIoMYXbMxaCgxU7GxynuKcZ7Wp5gz8GsXIEjnybSGY2u4OfIjee Rtc+r9WkKRZW1WnztQCvwb6JMrtenRXhtGf6+Hlz20BbDRKPllIpCPRuD1OBBRKeUx qi+0gZV91sSfeXcNvB8f9HMesxfJFvmqmxxc0TPekSo6VaqiuGJVIJT5ppWHzuNCjp yt6409EOjce/3JtfR0RsoXudeLfL94q6aa2VM7Gpry+aT9ecv4pXNT/P2bizqPit5R 5aDBW0R05kCqXLyR/Wx6xNjsoSmRK88Z+tZZFKj4hnvPENGccuAW/WyFdzWmucqqG/ hLWbWTzcxdvkQ== Subject: Re: [clue] New framework I-D posted 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, 07 Mar 2013 14:50:55 -0000 On 3/7/13 11:21 AM, Christian Groves wrote: >>> [Duckworth, Mark] I agree, Paul. If this is what the group wants, >>> the framework document should clearly say CLUE devices follow all SDP >>> O/A rules. Should we also refer to some specific RFCs? >> >> Since we are talking about SDP, we can at least reference 4566 and >> draft-ietf-mmusic-rfc4566bis. I don't think we need to mention any SDP >> extensions here unless we have reason to talk about them explicitly. > > [CNG] I'd be a little hesitant to mandate that a devices supporting CLUE > must support SDP O/A. That may not make much sense for non-SIP devices. > Yes I know this working group is only working on SIP CLUE but the > charter says we should identify interoperability obstacles in existing > open standards We are working on SIP CLUE. When doing that it is necessary to conform to SDP O/A. Normally I would think that there is no need to emphasize that because it is implicit in supporting SIP. But in this case there really may be a reason to talk about it: we do have another channel in which to negotiate things. Along the way there have been some suggestions that we might negotiate some media streams in the clue channel that weren't mentioned at all in SDP. I want to make it clear that we are *not* proposing to do that. If/when an H.323 version of clue is derived from this it can make the appropriate corresponding statements for H.323. Or do you think we need to be more restrictive in our use of SDP in order to facilitate interop with H.323? Thanks, Paul From pkyzivat@alum.mit.edu Thu Mar 7 06:58:34 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 7A35721F8C8D for ; Thu, 7 Mar 2013 06:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=0.242, 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 bdFq4i2af3fD for ; Thu, 7 Mar 2013 06:58:34 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id E23AF21F8C78 for ; Thu, 7 Mar 2013 06:58:33 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta05.westchester.pa.mail.comcast.net with comcast id 8bar1l0051c6gX855eyZH2; Thu, 07 Mar 2013 14:58:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 8eyZ1l0033ZTu2S3jeyZ7K; Thu, 07 Mar 2013 14:58:33 +0000 Message-ID: <5138AB18.7020205@alum.mit.edu> Date: Thu, 07 Mar 2013 22:58:32 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512EF700.2080207@nteczone.com> <9C23AB934B394845A7B228239B6EAF41539E72@CRPMBOXPRD01.polycom.com> <51381304.7010706@nteczone.com> In-Reply-To: <51381304.7010706@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=1362668313; bh=pkj0Tqseut78pnpE4n8UzUlVvM2L2Mm24j0SLARtJsE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rhQsq2s+x5daZCiqeWxFPGMU4Rn8q6e4Bk/34LWOPX7iC2f5xQORVIpHYRnoDEHVv CcvjbWuh9icbkJGeBn5d6yujfjc9l2Gtkv2C5W7BKeQVICHPvfNZBH2wr/ssUQhbvb vc/vxK2aanMm/0xi+3gbufSfq16OuEwtwgkopiQebAKXmfRMK+JNWVhbnba7f0otk3 EPLlNrq7e6U5RwCrjb+joVNzyJA9aIYVQHlROiKQGo3IrKagIIEcFlbMZb7cXYBaKA 1XaUJAKHzxH1lWKLSEcGkifA1AMDUDobAQgfaeer2C7K0LBpWfGiVUpx/W6wkLQ3pm JMPGZMdF2vyOw== Subject: Re: [clue] New framework I-D posted 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, 07 Mar 2013 14:58:34 -0000 On 3/7/13 12:09 PM, Christian Groves wrote: >>> Section 9. pg. 32 para.4: Not sure that each Advertise is >>> acknowledged by a >>> Configure. Acknowledge of the receipt of a message and configuration >>> could >>> be separate. >> [Duckworth, Mark] The intent is to say something like the Consumer >> must send a new Configure in response to receiving an Advertisement. >> Does that make more sense? I agree this could be separate from >> acknowledging receipt of the Advertisement. > [CNG] For the initial Advertisement the Consumer must send a Configure. > For subsequent Advertisements the consumer only has to send a Configure > if something in the new Advertisement has changed the consumer state and > it needs to send a Configure. The consumer should always ack/nack the > reception of an Advertisement. IMO this starts to get into protocol details. So I would like to avoid talking about this in the FW if possible. If it seems necessary to talk about it, then we will need to be careful to synchronize with the signaling. Thanks, Paul From pkyzivat@alum.mit.edu Thu Mar 7 07:44: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 A922121F8DA6 for ; Thu, 7 Mar 2013 07:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.205 X-Spam-Level: X-Spam-Status: No, score=-0.205 tagged_above=-999 required=5 tests=[AWL=0.232, 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 fJmHB-6WOQBV for ; Thu, 7 Mar 2013 07:44:49 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A36C121F8D9C for ; Thu, 7 Mar 2013 07:44:49 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8dUc1l02G1YDfWL53fkpE6; Thu, 07 Mar 2013 15:44:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id 8fko1l01N3ZTu2S3gfkogN; Thu, 07 Mar 2013 15:44:49 +0000 Message-ID: <5138B5F0.5070300@alum.mit.edu> Date: Thu, 07 Mar 2013 23:44:48 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> In-Reply-To: <061401ce1b31$a124bd10$e36e3730$@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=1362671089; bh=MBYpPRVqlyszTUn9xOKi859RTCHiyKXDZpBkBZj45mc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nL8/n3vKYOEHMxoS2o68/3vqUl3TY/OKbmWuaHU2ubysuqUuULrz8kDvyIUi7dCRy C8rf5y22l/y0I8UvwgA5wy/dQiSCxuktR1IVzNqttT4/tjAIwGHHJQ6i/Y/MF0YlV1 0VIfoSYwzAj5L605dbd89Su3LVil0WuCRgXaskbY4VkCI04Uqz1LXdyviLcSqNzbWJ YugI4LGw7vA9sZvGRWgK/gljK1sHdWk+7EWdVpakVgP2VHUJpXcGI9z5B97u70Dehy 6dhoSIPc0KMoiEZnGEyehIcl+0J9HSzXZCUdBOKONtfxsfOh5et7yqfAohuXXmWp/V L4/LUHcjMk+vA== Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 15:44:50 -0000 On 3/7/13 8:45 PM, Roni Even wrote: > Hi, > I agree about the single media type. > Still we can use capture scene entry as a shorthand in the simultaneous set. > > A Scene has capture scene entries where, as far as I understand, the entries > are not simultaneous, you can choose one or part of one, so you cannot have > a whole scene as a simultaneous set. IMO putting a whole scene in a simultaneous set is just a shorthand for putting all the captures in that scene into the simultaneous set. I think that should be ok when it is true. In some cases it may be true, and in other cases not. The complication with putting in the whole scene is that it will contain both audio and video entries. So what does that mean? If we want, we could say that a simultaneous set with both audio and video entries is just shorthand for two sets - one with the audio entries and one with the video entries. Thanks, Paul > Capture scene entry has media of same type. > > > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 07 March, 2013 6:52 AM > To: clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets > > Hello, > > I agree with Mark's original conclusions. I also tend to agree with item > 2 below. > > Regards, Christian > > On 7/03/2013 5:58 AM, Duckworth, Mark wrote: >> Hi Paul, >> >> I was assuming your item 2 is what we would do. But it could be open for > discussion. >> >>> 2) keep the current assumption that a simultaneous set applies to >>> only one medium. If a set contains references to CSs, factor those by >>> media type, and create multiple sets - one for each medium. >> Mark >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Wednesday, March 06, 2013 10:13 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] comments to framework 09 - simultaneous sets >>> >>> Mark, >>> >>> I agree with all you say below. >>> >>> But this does lead to another related issue that needs some > consideration. >>> Until now I think we have said that a single simultaneous set should >>> mention only a single medium - voice or video. When we permit it to >>> reference a complete scene it will have entries for different kinds >>> of media. So what does that mean? >>> >>> Having simultaneous sets only reference a single medium implies that >>> simultaneity across media types is implicit. I wonder if that is really > true. >>> >>> Some possible resolutions to this: >>> >>> 1) keep the current assumption that a simultaneous set applies to >>> only one medium, and to preserve that forbid the inclusion of a >>> complete CS if it contains more than one type of medium. >>> >>> 2) keep the current assumption that a simultaneous set applies to >>> only one medium. If a set contains references to CSs, factor those by >>> media type, and create multiple sets - one for each medium. >>> >>> 3) forbid references to CSs in simultaneous sets >>> >>> 4) change the definition of simultaneous sets so that they explicitly >>> define permitted simultaneity among multiple media types. >>> >>> I haven't decided my own preference among the above. >>> >>> Thanks, >>> Paul >>> >>> >>> >>> On 3/6/13 10:32 PM, Duckworth, Mark wrote: >>>> I will try to summarize what I think the conclusions are from this > thread. >>>> >>>> Point 1 - we generally agree simultaneity restrictions are not just >>>> about >>> physical constraints, there are other reasons. >>>> Point 2 - we should remove the bit about "may not make sense to do so". >>>> >>>> Point 3 - we generally agree it would be good to allow expressing >>> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set >>> Entries, as well as Media Captures that the Provider can provide > simultaneously. >>>> Point 4 - we generally agree (again) we do not want to define other >>>> ways of >>> expressing Simultaneous Transmission Sets, such as by mutual >>> exclusion or with logical operators. >>>> Regards, >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Roberta Presta >>>>> Sent: Wednesday, February 27, 2013 1:47 PM >>>>> To: clue@ietf.org >>>>> Subject: [clue] comments to framework 09 - simultaneous sets >>>>> >>>>> Hi all, >>>>> >>>>> sorry for boring you always with the same things :) >>>>> >>>>> When I read Section 6.3 "Simultaneous Transmission Set Constraint", >>>>> I noticed a couple of things: >>>>> >>>>> 1) the only motivation that has been provided to justify the >>>>> definition of simultaneous sets is the fact that captures generated >>>>> from the same device cannot be sent simultaneously. However, there >>>>> can be other motivations behind the need of expressing simultaneity >>>>> constraints (leaving resource constraints handled by encoding >>>>> groups and other stuff such as max- >>>>> encoding- and so on). >>>>> Citing Andy Pepperel in >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, >>>>> simultaneous sets can be used by MCUs that might not want to be >>>>> obliged to provide some capture simultaneously, in order to avoid >>> overloading. >>>>> I think that these other motivations should be explicitely >>>>> mentioned in the framework document to explain that simultaneity >>>>> limitations may not be due only to physical constraints. >>>>> >>>>> 2) Copying from the document: "Simultaneous transmission sets are >>>>> expressed as sets of the Media Captures that could physically be >>>>> transmitted at the same time (though it may not make sense to do so). " >>>>> Does it mean that even if there is a large set of captures able to >>>>> be sent simultaneously, it may not make sense, from the consumer's >>>>> perspective, to receive them all together? Maybe rewording is >>>>> needed >>> here. >>>>> 3) Again, on the design (and definition) of the simultaneous sets. >>>>> >>>>> Simultaneous sets, as defined in the framework, are *all* the >>>>> groups of >>>>> *captures* that can be sent together. >>>>> The consumer presumably has to check if the set of captures he >>>>> wants is fully >>>>> *included* in almost one of the listed ones. >>>>> If not, he has to re-structure the configure to fit simultaneity >>>>> constraints expressed by the provider. >>>>> (Is that the expected behavior of the consumer?) >>>>> >>>>> I was thinking that each set can be expressed also in terms of >>>>> capture scene entries, or capture scene as a whole, for example: >>>>> 1) CSE1, CSE2, CS3, VC1, CS5 >>>>> 2) CSE1, CSE4, CS3, VC1, CS5 >>>>> .... >>>>> Where CSE* identifies a capture scene entry, and CS* identifies a >>>>> capture scene. >>>>> That can allow to make simultaneous sets more synthetic by >>>>> exploiting the capture aggregates the framework envisions. It can >>>>> be particularly useful to MCUs that want to offer just subsets of >>>>> the complete list of capture scenes they receive from multiple > contributors. >>>>> >>>>> >>>>> 4) Some further reasoning. >>>>> >>>>> In some cases it can be more efficient to express only mutual >>>>> exclusion constraints. >>>>> We could discuss about envisioning a section of information named >>>>> "simultaneity constraints" that can include a list of simultaneous >>>>> sets and a list of mutual exclusion conditions to be checked on the >>> consumer's side. >>>>> For example, if a media provider offers many captures, and has only >>>>> 4 mutual exclusion conditions, instead of listing all the possible >>>>> simultaneous sets, he can just provide the 4 mutual exclusion >>>>> conditions >>> to the consumer. >>>>> Another alternative is also Christer Holmberg's proposal in >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, >>>>> where simultaneity constraints are logical conditions that the >>>>> consumer has to verify before issuing a configure to the provider. >>>>> The example was: >>>>> >>>>> "(CSE-X AND CSE-Y) OR CSE-Z. >>>>> >>>>> This means that the provider can provide CSE-X and CSE Y (and all >>>>> captures associated with CSE-X and CSE-Y) simultaneously, or that >>>>> the provider can provide CSE-Z (and all captures associated with > CSE-Z)." >>>>> >>>>> Do you think we should stuck on the framework solution or also >>>>> consider the aforementioned alternatives? >>>>> I promise I stop thinking about it! >>>>> >>>>> RP >>>>> >>>>> -- >>>>> Roberta Presta, Ph.D. Student >>>>> Dipartimento di Ingegneria Elettrica e delle Tecnologie >>>>> dell'Informazione >>>>> (DIETI) Universita' degli Studi di Napoli "Federico II" >>>>> Via Claudio 21 -- 80125 Napoli (Italy) >>>>> Phone: +390817683821 - Fax: +390817683816 >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Mar 7 07:47:38 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 CFEF021F8D94 for ; Thu, 7 Mar 2013 07:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.214 X-Spam-Level: X-Spam-Status: No, score=-0.214 tagged_above=-999 required=5 tests=[AWL=0.223, 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 VpFT4oHDEanQ for ; Thu, 7 Mar 2013 07:47:37 -0800 (PST) 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 69F8421F8B1E for ; Thu, 7 Mar 2013 07:47:37 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta14.westchester.pa.mail.comcast.net with comcast id 8daJ1l0030Fqzac5EfnTyu; Thu, 07 Mar 2013 15:47:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 8fnS1l00f3ZTu2S3UfnSi6; Thu, 07 Mar 2013 15:47:27 +0000 Message-ID: <5138B68E.6010203@alum.mit.edu> Date: Thu, 07 Mar 2013 23:47:26 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B114B24@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=1362671247; bh=frFxz1S8I7cM05Jod9fMcvk2S9aqFCTPWpmtJh/2Pfk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NBq2Hfr2zBVlKF2dtQSl2FuXQJllgFutl/ANDVdv27E8D7fcGk4DwGb8zEq5aWeX9 QpQiSqsEkoCVtZpSZhs6mX6sag1xuOchL3W5Ua6T6CbE62msBQDi10YWndSJdF6cGW SphT0WsG/5zVtdINCdGyodrJBTRByNltq+pLILyrp9RXQvQYuz3bNiNJmmKcMVQhAa DFR6DO/aunzWSPXPvP0hbnjb39hbSKn1Bf0gVfDXulvOfGnto1dypAm2dctplGCuYn OoA5N2KSES9B7gXPgaGJyXVVt19BKS6rQcIMMG9Eb1KWK5VkQttfVkUsVRzo7S5WK0 CLN/dFbU2QF7Q== Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 15:47:39 -0000 On 3/7/13 8:49 PM, Christer Holmberg wrote: > Hi, > > Do we assume there is a one-to-one mapping between video and audio captures? > > For example, assume one video capture has the role "manager". > > That doesn't mean that there will be an audio capture with the same role, because the audio capture may cover a bigger area, including many persons. > > So, if I show the manager on my screen, how do I know which audio capture to choose? I too have wondered about this, and have no great answer. The simple answer is use spatial coordinates. But I'm not at all convinced that is a complete answer. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: 7. maaliskuuta 2013 14:45 > To: 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets > > Hi, > I agree about the single media type. > Still we can use capture scene entry as a shorthand in the simultaneous set. > > A Scene has capture scene entries where, as far as I understand, the entries are not simultaneous, you can choose one or part of one, so you cannot have a whole scene as a simultaneous set. > > Capture scene entry has media of same type. > > > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 07 March, 2013 6:52 AM > To: clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets > > Hello, > > I agree with Mark's original conclusions. I also tend to agree with item > 2 below. > > Regards, Christian > > On 7/03/2013 5:58 AM, Duckworth, Mark wrote: >> Hi Paul, >> >> I was assuming your item 2 is what we would do. But it could be open >> for > discussion. >> >>> 2) keep the current assumption that a simultaneous set applies to >>> only one medium. If a set contains references to CSs, factor those by >>> media type, and create multiple sets - one for each medium. >> Mark >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Wednesday, March 06, 2013 10:13 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] comments to framework 09 - simultaneous sets >>> >>> Mark, >>> >>> I agree with all you say below. >>> >>> But this does lead to another related issue that needs some > consideration. >>> Until now I think we have said that a single simultaneous set should >>> mention only a single medium - voice or video. When we permit it to >>> reference a complete scene it will have entries for different kinds >>> of media. So what does that mean? >>> >>> Having simultaneous sets only reference a single medium implies that >>> simultaneity across media types is implicit. I wonder if that is >>> really > true. >>> >>> Some possible resolutions to this: >>> >>> 1) keep the current assumption that a simultaneous set applies to >>> only one medium, and to preserve that forbid the inclusion of a >>> complete CS if it contains more than one type of medium. >>> >>> 2) keep the current assumption that a simultaneous set applies to >>> only one medium. If a set contains references to CSs, factor those by >>> media type, and create multiple sets - one for each medium. >>> >>> 3) forbid references to CSs in simultaneous sets >>> >>> 4) change the definition of simultaneous sets so that they explicitly >>> define permitted simultaneity among multiple media types. >>> >>> I haven't decided my own preference among the above. >>> >>> Thanks, >>> Paul >>> >>> >>> >>> On 3/6/13 10:32 PM, Duckworth, Mark wrote: >>>> I will try to summarize what I think the conclusions are from this > thread. >>>> >>>> Point 1 - we generally agree simultaneity restrictions are not just >>>> about >>> physical constraints, there are other reasons. >>>> Point 2 - we should remove the bit about "may not make sense to do so". >>>> >>>> Point 3 - we generally agree it would be good to allow expressing >>> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set >>> Entries, as well as Media Captures that the Provider can provide > simultaneously. >>>> Point 4 - we generally agree (again) we do not want to define other >>>> ways of >>> expressing Simultaneous Transmission Sets, such as by mutual >>> exclusion or with logical operators. >>>> Regards, >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Roberta Presta >>>>> Sent: Wednesday, February 27, 2013 1:47 PM >>>>> To: clue@ietf.org >>>>> Subject: [clue] comments to framework 09 - simultaneous sets >>>>> >>>>> Hi all, >>>>> >>>>> sorry for boring you always with the same things :) >>>>> >>>>> When I read Section 6.3 "Simultaneous Transmission Set Constraint", >>>>> I noticed a couple of things: >>>>> >>>>> 1) the only motivation that has been provided to justify the >>>>> definition of simultaneous sets is the fact that captures generated >>>>> from the same device cannot be sent simultaneously. However, there >>>>> can be other motivations behind the need of expressing simultaneity >>>>> constraints (leaving resource constraints handled by encoding >>>>> groups and other stuff such as max- >>>>> encoding- and so on). >>>>> Citing Andy Pepperel in >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, >>>>> simultaneous sets can be used by MCUs that might not want to be >>>>> obliged to provide some capture simultaneously, in order to avoid >>> overloading. >>>>> I think that these other motivations should be explicitely >>>>> mentioned in the framework document to explain that simultaneity >>>>> limitations may not be due only to physical constraints. >>>>> >>>>> 2) Copying from the document: "Simultaneous transmission sets are >>>>> expressed as sets of the Media Captures that could physically be >>>>> transmitted at the same time (though it may not make sense to do so). " >>>>> Does it mean that even if there is a large set of captures able to >>>>> be sent simultaneously, it may not make sense, from the consumer's >>>>> perspective, to receive them all together? Maybe rewording is >>>>> needed >>> here. >>>>> 3) Again, on the design (and definition) of the simultaneous sets. >>>>> >>>>> Simultaneous sets, as defined in the framework, are *all* the >>>>> groups of >>>>> *captures* that can be sent together. >>>>> The consumer presumably has to check if the set of captures he >>>>> wants is fully >>>>> *included* in almost one of the listed ones. >>>>> If not, he has to re-structure the configure to fit simultaneity >>>>> constraints expressed by the provider. >>>>> (Is that the expected behavior of the consumer?) >>>>> >>>>> I was thinking that each set can be expressed also in terms of >>>>> capture scene entries, or capture scene as a whole, for example: >>>>> 1) CSE1, CSE2, CS3, VC1, CS5 >>>>> 2) CSE1, CSE4, CS3, VC1, CS5 >>>>> .... >>>>> Where CSE* identifies a capture scene entry, and CS* identifies a >>>>> capture scene. >>>>> That can allow to make simultaneous sets more synthetic by >>>>> exploiting the capture aggregates the framework envisions. It can >>>>> be particularly useful to MCUs that want to offer just subsets of >>>>> the complete list of capture scenes they receive from multiple > contributors. >>>>> >>>>> >>>>> 4) Some further reasoning. >>>>> >>>>> In some cases it can be more efficient to express only mutual >>>>> exclusion constraints. >>>>> We could discuss about envisioning a section of information named >>>>> "simultaneity constraints" that can include a list of simultaneous >>>>> sets and a list of mutual exclusion conditions to be checked on the >>> consumer's side. >>>>> For example, if a media provider offers many captures, and has only >>>>> 4 mutual exclusion conditions, instead of listing all the possible >>>>> simultaneous sets, he can just provide the 4 mutual exclusion >>>>> conditions >>> to the consumer. >>>>> Another alternative is also Christer Holmberg's proposal in >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, >>>>> where simultaneity constraints are logical conditions that the >>>>> consumer has to verify before issuing a configure to the provider. >>>>> The example was: >>>>> >>>>> "(CSE-X AND CSE-Y) OR CSE-Z. >>>>> >>>>> This means that the provider can provide CSE-X and CSE Y (and all >>>>> captures associated with CSE-X and CSE-Y) simultaneously, or that >>>>> the provider can provide CSE-Z (and all captures associated with > CSE-Z)." >>>>> >>>>> Do you think we should stuck on the framework solution or also >>>>> consider the aforementioned alternatives? >>>>> I promise I stop thinking about it! >>>>> >>>>> RP >>>>> >>>>> -- >>>>> Roberta Presta, Ph.D. Student >>>>> Dipartimento di Ingegneria Elettrica e delle Tecnologie >>>>> dell'Informazione >>>>> (DIETI) Universita' degli Studi di Napoli "Federico II" >>>>> Via Claudio 21 -- 80125 Napoli (Italy) >>>>> Phone: +390817683821 - Fax: +390817683816 >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Mar 7 08:51:11 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 6E85821F8A4E for ; Thu, 7 Mar 2013 08:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 iG6-0goZi8i5 for ; Thu, 7 Mar 2013 08:51:10 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C2B9D21F8A2A for ; Thu, 7 Mar 2013 08:51:06 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-29-5138c57996fa Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 82.38.10459.975C8315; Thu, 7 Mar 2013 17:51:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 17:51:05 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiYs+6AgAALTQCAAD7qAIAApfyAgACEJACAABFUkIAAIY8AgAAhbAU= Date: Thu, 7 Mar 2013 16:51:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B114EC2@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se>, <5138B68E.6010203@alum.mit.edu> In-Reply-To: <5138B68E.6010203@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+JvjW7lUYtAg3P/rSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjZMc09oKZoRWLWi+wNjCece1i5OSQEDCR WLf8BhOELSZx4d56ti5GLg4hgUOMEt/XTWGFcBYxSkz70c3SxcjBwSZgIdH9TxukQUTAU2LH xynMILawgINEyy+QepC4o8SqVfNYIOwkiY7uH2A2i4CKxLXvN9hBbF4Bb4llL24zQsxvZJZ4 +WIGWDOngI7E4f4HjCA2I9BF30+tAbuOWUBc4taT+VCXCkgs2XOeGcIWlXj5+B8rhK0o0f60 gRGiXkdiwe5PbBC2tsSyha+ZIRYLSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsY2XMTM3PS yw03MQKj4eCW37o7GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD Y575x1brnKyqbbaPLN0rVoXKfvs3J1eZa49CN69w8s/NSW0PTzIXdArd5r6zfWrlIymp52rW j8/NC2q9MOe4ZuC0s6ES1rsPnK1Kvf+OYxHjSgWu/xMWZ9d+4Lz1+qprzoxYX6/Ezyc9rPf/ yXfiYNZ7k65/aY1FluXTwzyapcs76iV3/2ZmUGIpzkg01GIuKk4EAJ03ZD1UAgAA Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 16:51:11 -0000 Hi, >> Do we assume there is a one-to-one mapping between video and audio captu= res? >> >> For example, assume one video capture has the role "manager". >> >> That doesn't mean that there will be an audio capture with the same role= , because the audio capture may cover a bigger area, including many persons= . >> >> So, if I show the manager on my screen, how do I know which audio captur= e to choose? > > I too have wondered about this, and have no great answer. > > The simple answer is use spatial coordinates. But I'm not at all > convinced that is a complete answer. Also, you can have multiple video CSEs, and multiple audio CSEs, and the ch= oise of audio CSE may depend on the choise of video CSE. So, is there a rea= son why we can't put different media types in the same CSE, if they are ass= ociated? I think it would help alot. But, that still doesn't solve the problem about, though, if you e.g. from a= CSE only choose a specific set of video captures, and also want the corres= ponding audio captures. Maybe spatial coordinates helps there. Regards, Christer > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of R= oni Even > Sent: 7. maaliskuuta 2013 14:45 > To: 'Christian Groves'; clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets > > Hi, > I agree about the single media type. > Still we can use capture scene entry as a shorthand in the simultaneous s= et. > > A Scene has capture scene entries where, as far as I understand, the entr= ies are not simultaneous, you can choose one or part of one, so you cannot = have a whole scene as a simultaneous set. > > Capture scene entry has media of same type. > > > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of C= hristian Groves > Sent: 07 March, 2013 6:52 AM > To: clue@ietf.org > Subject: Re: [clue] comments to framework 09 - simultaneous sets > > Hello, > > I agree with Mark's original conclusions. I also tend to agree with item > 2 below. > > Regards, Christian > > On 7/03/2013 5:58 AM, Duckworth, Mark wrote: >> Hi Paul, >> >> I was assuming your item 2 is what we would do. But it could be open >> for > discussion. >> >>> 2) keep the current assumption that a simultaneous set applies to >>> only one medium. If a set contains references to CSs, factor those by >>> media type, and create multiple sets - one for each medium. >> Mark >> >>> -----Original Message----- >>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: Wednesday, March 06, 2013 10:13 AM >>> To: clue@ietf.org >>> Subject: Re: [clue] comments to framework 09 - simultaneous sets >>> >>> Mark, >>> >>> I agree with all you say below. >>> >>> But this does lead to another related issue that needs some > consideration. >>> Until now I think we have said that a single simultaneous set should >>> mention only a single medium - voice or video. When we permit it to >>> reference a complete scene it will have entries for different kinds >>> of media. So what does that mean? >>> >>> Having simultaneous sets only reference a single medium implies that >>> simultaneity across media types is implicit. I wonder if that is >>> really > true. >>> >>> Some possible resolutions to this: >>> >>> 1) keep the current assumption that a simultaneous set applies to >>> only one medium, and to preserve that forbid the inclusion of a >>> complete CS if it contains more than one type of medium. >>> >>> 2) keep the current assumption that a simultaneous set applies to >>> only one medium. If a set contains references to CSs, factor those by >>> media type, and create multiple sets - one for each medium. >>> >>> 3) forbid references to CSs in simultaneous sets >>> >>> 4) change the definition of simultaneous sets so that they explicitly >>> define permitted simultaneity among multiple media types. >>> >>> I haven't decided my own preference among the above. >>> >>> Thanks, >>> Paul >>> >>> >>> >>> On 3/6/13 10:32 PM, Duckworth, Mark wrote: >>>> I will try to summarize what I think the conclusions are from this > thread. >>>> >>>> Point 1 - we generally agree simultaneity restrictions are not just >>>> about >>> physical constraints, there are other reasons. >>>> Point 2 - we should remove the bit about "may not make sense to do so"= . >>>> >>>> Point 3 - we generally agree it would be good to allow expressing >>> Simultaneous Transmission Sets as lists of Capture Sets, Capture Set >>> Entries, as well as Media Captures that the Provider can provide > simultaneously. >>>> Point 4 - we generally agree (again) we do not want to define other >>>> ways of >>> expressing Simultaneous Transmission Sets, such as by mutual >>> exclusion or with logical operators. >>>> Regards, >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On >>>>> Behalf Of Roberta Presta >>>>> Sent: Wednesday, February 27, 2013 1:47 PM >>>>> To: clue@ietf.org >>>>> Subject: [clue] comments to framework 09 - simultaneous sets >>>>> >>>>> Hi all, >>>>> >>>>> sorry for boring you always with the same things :) >>>>> >>>>> When I read Section 6.3 "Simultaneous Transmission Set Constraint", >>>>> I noticed a couple of things: >>>>> >>>>> 1) the only motivation that has been provided to justify the >>>>> definition of simultaneous sets is the fact that captures generated >>>>> from the same device cannot be sent simultaneously. However, there >>>>> can be other motivations behind the need of expressing simultaneity >>>>> constraints (leaving resource constraints handled by encoding >>>>> groups and other stuff such as max- >>>>> encoding- and so on). >>>>> Citing Andy Pepperel in >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg02182.html, >>>>> simultaneous sets can be used by MCUs that might not want to be >>>>> obliged to provide some capture simultaneously, in order to avoid >>> overloading. >>>>> I think that these other motivations should be explicitely >>>>> mentioned in the framework document to explain that simultaneity >>>>> limitations may not be due only to physical constraints. >>>>> >>>>> 2) Copying from the document: "Simultaneous transmission sets are >>>>> expressed as sets of the Media Captures that could physically be >>>>> transmitted at the same time (though it may not make sense to do so).= " >>>>> Does it mean that even if there is a large set of captures able to >>>>> be sent simultaneously, it may not make sense, from the consumer's >>>>> perspective, to receive them all together? Maybe rewording is >>>>> needed >>> here. >>>>> 3) Again, on the design (and definition) of the simultaneous sets. >>>>> >>>>> Simultaneous sets, as defined in the framework, are *all* the >>>>> groups of >>>>> *captures* that can be sent together. >>>>> The consumer presumably has to check if the set of captures he >>>>> wants is fully >>>>> *included* in almost one of the listed ones. >>>>> If not, he has to re-structure the configure to fit simultaneity >>>>> constraints expressed by the provider. >>>>> (Is that the expected behavior of the consumer?) >>>>> >>>>> I was thinking that each set can be expressed also in terms of >>>>> capture scene entries, or capture scene as a whole, for example: >>>>> 1) CSE1, CSE2, CS3, VC1, CS5 >>>>> 2) CSE1, CSE4, CS3, VC1, CS5 >>>>> .... >>>>> Where CSE* identifies a capture scene entry, and CS* identifies a >>>>> capture scene. >>>>> That can allow to make simultaneous sets more synthetic by >>>>> exploiting the capture aggregates the framework envisions. It can >>>>> be particularly useful to MCUs that want to offer just subsets of >>>>> the complete list of capture scenes they receive from multiple > contributors. >>>>> >>>>> >>>>> 4) Some further reasoning. >>>>> >>>>> In some cases it can be more efficient to express only mutual >>>>> exclusion constraints. >>>>> We could discuss about envisioning a section of information named >>>>> "simultaneity constraints" that can include a list of simultaneous >>>>> sets and a list of mutual exclusion conditions to be checked on the >>> consumer's side. >>>>> For example, if a media provider offers many captures, and has only >>>>> 4 mutual exclusion conditions, instead of listing all the possible >>>>> simultaneous sets, he can just provide the 4 mutual exclusion >>>>> conditions >>> to the consumer. >>>>> Another alternative is also Christer Holmberg's proposal in >>>>> http://www.ietf.org/mail-archive/web/clue/current/msg02257.html, >>>>> where simultaneity constraints are logical conditions that the >>>>> consumer has to verify before issuing a configure to the provider. >>>>> The example was: >>>>> >>>>> "(CSE-X AND CSE-Y) OR CSE-Z. >>>>> >>>>> This means that the provider can provide CSE-X and CSE Y (and all >>>>> captures associated with CSE-X and CSE-Y) simultaneously, or that >>>>> the provider can provide CSE-Z (and all captures associated with > CSE-Z)." >>>>> >>>>> Do you think we should stuck on the framework solution or also >>>>> consider the aforementioned alternatives? >>>>> I promise I stop thinking about it! >>>>> >>>>> RP >>>>> >>>>> -- >>>>> Roberta Presta, Ph.D. Student >>>>> Dipartimento di Ingegneria Elettrica e delle Tecnologie >>>>> dell'Informazione >>>>> (DIETI) Universita' degli Studi di Napoli "Federico II" >>>>> Via Claudio 21 -- 80125 Napoli (Italy) >>>>> Phone: +390817683821 - Fax: +390817683816 >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Mar 7 09:14:13 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 B243521F84DF for ; Thu, 7 Mar 2013 09:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.216 X-Spam-Level: X-Spam-Status: No, score=-0.216 tagged_above=-999 required=5 tests=[AWL=0.221, 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 Yc7yBFgveG5f for ; Thu, 7 Mar 2013 09:14:13 -0800 (PST) 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 1295A21F8501 for ; Thu, 7 Mar 2013 09:14:09 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta09.westchester.pa.mail.comcast.net with comcast id 8cjm1l0020xGWP859hE9Ep; Thu, 07 Mar 2013 17:14:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id 8hE91l00S3ZTu2S3YhE9UR; Thu, 07 Mar 2013 17:14:09 +0000 Message-ID: <5138CAE0.4010103@alum.mit.edu> Date: Fri, 08 Mar 2013 01:14:08 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se>, <5138B68E.6010203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B114EC2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B114EC2@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=1362676449; bh=2sSuXMj+q3OCOLmw/QflJXnjev6t/I1l5SUn9CNPxhY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hFXZensQSPGnS+8rnsX97aDwS+v8R4fz02YvZZWxmKR9DCIOBlXCpiTUqOo9f2/fY yCe9+EznafHMwj/WFcmLZQFVzzuwkI5md3w2i6mbgE7E6uoU307q3uOWJrvGi8kOUO adZLPn919QymjhwjLrt5VO+7PdoZYyqiFg7RqIQcOO+dMCT+CBpkJoAROdocO0jKpu 2QEW4OiiqLFPmxn2qQf1uTBIPUOPRGnoDF0xDMPQmfSFLo6tesWEYPXxCggfPaypst JYN1tMVbGMmHUewslejhMc5cqoQAbQqWVOd96vQrUUFkVgUAx0ywNT3G7ryn1F0x7J NaS800PTfEFNA== Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:14:14 -0000 On 3/8/13 12:51 AM, Christer Holmberg wrote: > > Hi, > >>> Do we assume there is a one-to-one mapping between video and audio captures? >>> >>> For example, assume one video capture has the role "manager". >>> >>> That doesn't mean that there will be an audio capture with the same role, because the audio capture may cover a bigger area, including many persons. >>> >>> So, if I show the manager on my screen, how do I know which audio capture to choose? >> >> I too have wondered about this, and have no great answer. >> >> The simple answer is use spatial coordinates. But I'm not at all >> convinced that is a complete answer. > > Also, you can have multiple video CSEs, and multiple audio CSEs, and the choise of audio CSE may depend on the choise of video CSE. So, is there a reason why we can't put different media types in the same CSE, if they are associated? I think it would help alot. > > But, that still doesn't solve the problem about, though, if you e.g. from a CSE only choose a specific set of video captures, and also want the corresponding audio captures. Maybe spatial coordinates helps there. I agree that this seems to be an issue that deserves more study. Is somebody willing to think hard about it and come back with an analysis? It certainly would be possible to redefine CSEs so that they contain captures of different media types. The good of it is that it mostly solves the problem you present. The bad of it is that it will increase the number of CSEs. (If under the current scheme there are N audio CSEs and M video CSEs (total N+M) then under this new approach there would be N*M CSEs, and each would be bigger.) But for common cases this may still be manageable. Thanks, Paul From christer.holmberg@ericsson.com Thu Mar 7 09:30:14 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 5117A21F8C46 for ; Thu, 7 Mar 2013 09:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, 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 WwKYgi+eIC3O for ; Thu, 7 Mar 2013 09:30:13 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 361E221F8C2B for ; Thu, 7 Mar 2013 09:30:13 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-e6-5138cea4952a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 02.FF.32353.4AEC8315; Thu, 7 Mar 2013 18:30:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 18:30:11 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiYs+6AgAALTQCAAD7qAIAApfyAgACEJACAABFUkIAAIY8AgAAhbAX///bNAIAAE9rg Date: Thu, 7 Mar 2013 17:30:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B115FD1@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se>, <5138B68E.6010203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B114EC2@ESESSMB209.ericsson.se> <5138CAE0.4010103@alum.mit.edu> In-Reply-To: <5138CAE0.4010103@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvje6ScxaBBlsnClvsP3WZ2WLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGoe17WQt6BCr+3Z7K2sB4kaeLkZNDQsBE 4vGJ/ewQtpjEhXvr2boYuTiEBA4xSrzdN4kRwlnEKHG7qYmli5GDg03AQqL7nzZIg4iAlsSB K5dZQGxmAWWJrw2bmEBsYQEHiZZfU1ghahwlVq2axwJh50ksW3+HEcRmEVCRON9/hRFkJK+A t8TZfbUQq54yS/w4sQtsDqeAjkTrTpCDODkYgY77fmoNE8QucYlbT+YzQRwtILFkz3lmCFtU 4uXjf6wQtqLEx1f7GCHqdSQW7P7EBmFrSyxb+BqsnldAUOLkzCcsExjFZiEZOwtJyywkLbOQ tCxgZFnFyJ6bmJmTXm6+iREYIwe3/DbYwbjpvtghRmkOFiVx3nDXCwFCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGCc2hqZztW9bcT54adwd3laXY0asgq58nyW86hYnTnkW+W3PzkOqWgYv Ds6Qu/dFpPtIyKSkTTIvfwVb3pyuVWDPz/KYdVngNm9g0Bcemy3+Wu3a2rNXHx1UlZUTL/7z 8P/RfWd67hwLTPmimVq4Me6Hiky9bc/xkK2/ZE2Eg7+/yEy4fa9YVImlOCPRUIu5qDgRAKo4 phhfAgAA Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2013 17:30:14 -0000 Hi, >>>> Do we assume there is a one-to-one mapping between video and audio cap= tures? >>>> >>>> For example, assume one video capture has the role "manager". >>>> >>>> That doesn't mean that there will be an audio capture with the same ro= le, because the audio capture may cover a bigger area, including many perso= ns. >>>> >>>> So, if I show the manager on my screen, how do I know which audio capt= ure to choose? >>> >>> I too have wondered about this, and have no great answer. >>> >>> The simple answer is use spatial coordinates. But I'm not at all=20 >>> convinced that is a complete answer. >> >> Also, you can have multiple video CSEs, and multiple audio CSEs, and the= choise of audio CSE may depend on the choise of video CSE. So, is there a = reason why we can't put different media types in the same CSE, if they are = associated? I think it would help alot. >> >> But, that still doesn't solve the problem about, though, if you e.g. fro= m a CSE only choose a specific set of video captures, and also want the cor= responding audio captures. Maybe spatial coordinates helps there. > > I agree that this seems to be an issue that deserves more study. > Is somebody willing to think hard about it and come back with an analysis= ? > > It certainly would be possible to redefine CSEs so that they contain capt= ures of different media types. The good of it is that it mostly solves the = problem you present. It helps picking CSEs, but it still does not map individual captures :) >The bad of it is that it will increase the number of CSEs. (If under the c= urrent scheme there are N audio CSEs and M video CSEs (total N+M) then unde= r this new approach there would be N*M CSEs, and each would be >bigger.) But for common cases this may still be manageable. Another way would be to keep them separate, but assign an identifier for ea= ch CSE, and then e.g. in each video CSE list the identifiers of all audio C= SEs that can be used with that particular video CSE. Regards, Christer From mary.ietf.barnes@gmail.com Thu Mar 7 10:08:16 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 7FAFE21F8992 for ; Thu, 7 Mar 2013 10:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.85 X-Spam-Level: X-Spam-Status: No, score=-102.85 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 KBBYoBrRxUBK for ; Thu, 7 Mar 2013 10:08:16 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6E21F8826 for ; Thu, 7 Mar 2013 10:08:15 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id k19so243959qcs.41 for ; Thu, 07 Mar 2013 10:08:15 -0800 (PST) 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=BCaHRQkNC69qeJY/lwsAUM/BrO2jDXsPIkK/S4c85mM=; b=H2dHovl+4jRzzoyHAcZccqxxrfeSPC7Nh+LdP52EGyo2yjmO6cNUTTKnnxt6BQUxFN lPNSBm0DBntD61VM+XnL1koztP/jx2d27RPpOYAemIbLwAk3qYtNPzEf757gvnwMA7Uk M1gtnvY0CRrT1gHJ91nOvWNbzzhCW0TS4q6B/lHKUOatkqKLmxZyCFS3KbgFu0570aqr 8Sk+YiPNBE7PKxS8CxJ0P4vMy5Ksp1HEvylbxIfHqEeoAmJIZ7M+tX4LjFRTbW6i/QLO 3Ampc3Ryl/qE4UDvWb+GDDIcf4ePkxUjloojicEPyd+7QvOOHP9bOtYz5apg+xMgeJs+ 0q6A== MIME-Version: 1.0 X-Received: by 10.224.186.212 with SMTP id ct20mr8770289qab.3.1362679695384; Thu, 07 Mar 2013 10:08:15 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 10:08:15 -0800 (PST) Date: Thu, 7 Mar 2013 12:08:15 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 18:08:16 -0000 I really think CLUE folks need to read this thread and understand the issues: http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html While we aren't defining an API, we are defining a application. I think it's important to carefully consider the tradeoffs in terms of how much is carried in SDP versus how much we can do with a CLUE specific protocol. I really, really think that the more we put in SDP, the less extensibility we will have for the CLUE application - I think we really, really need to carefully weigh the tradeoffs between tightly coupling the CLUE application to SDP versus minimizing the interactions and duplication of information. In one sense, this is a similar problem we faced with SIP conferencing. We defined some basic extensions that worked just fine. But, it would have been a bear to add all the additional functionality for complex scenarios to SIP. Instead, we defined XCON, which decouples the conferencing application from the session setup/signaling protocol. XCON is highly extensible and flexible and provides a rich set of application functionality. I believe we want to same with CLUE a Mary. From espeberg@cisco.com Thu Mar 7 10:32: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 472EA21F8A11 for ; Thu, 7 Mar 2013 10:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSDgGIAoGZ5p for ; Thu, 7 Mar 2013 10:32:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1603521F8A91 for ; Thu, 7 Mar 2013 10:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26829; q=dns/txt; s=iport; t=1362681173; x=1363890773; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uRFa9tC5In3+wqxcSP0ARb7FsZzhvDaeRIm90MvbEig=; b=aaXQH1wRBUqbbFy9D7gBaXmP1TW2C7qfCBx1d+z2J8iJBoIC38etW06C 1VEFNq26XdV3nm4h46LF0TuC3wwAVZ+X5LNg5Mx7LwLbn+lhGBC4K1uqU m4nPs5+p64I8IDIBB08Wsr8GnPDXaXgKozz6VCFa4IBfEQjI1WHsanK5X I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANfcOFGtJV2Z/2dsb2JhbABDhBvAMIFhFnSCLAEBAQQtXAIBCBEEAQELAhQHByERFAkIAgQBEgiHeQMPsXoNiSiJeIJMgRGBBiYRAQaCWWEDlGuNOYUYgwmBaT4 X-IronPort-AV: E=Sophos;i="4.84,803,1355097600"; d="scan'208,217";a="184961479" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 07 Mar 2013 18:32:47 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r27IWlpT027039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Mar 2013 18:32:47 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.247]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 12:32:47 -0600 From: "Espen Berger (espeberg)" To: Christer Holmberg , Roni Even , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkAAN77WAAAWGH4AAAXc2gAAAegoAAADWuoAAAMYJAAABxgcw Date: Thu, 7 Mar 2013 18:32:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> <061501ce1b32$91608660$b4219320$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B6A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B114B6A@ESESSMB209.ericsson.se> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.197] Content-Type: multipart/alternative; boundary="_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68B682xmbrcdx11ciscoc_" MIME-Version: 1.0 Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 18:32:56 -0000 --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68B682xmbrcdx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I suggest we split the problem into two parts. 1) Subscribe to virtual captures, allow to server to forward based on = information available on the server. The most normal scenario is to forward= based on audio activity. 2) Setting policy for how the server should switch streams. Policies c= ould be a. Active speaker (based on audio level) b. Round robin A client could then request two virtual streams (with capture id 1 and 2) w= ith policy 'active speaker', that should mean that the two loudest speaker = should be in either capture id 1 or 2, to avoid having the capture id chang= ing. -Espen From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: 7. mars 2013 14:14 To: Roni Even; clue@ietf.org Subject: Re: [clue] Active speaker a role? Hi, The MCU will advertise, to me, that it can provide three media captures (as= in your example). The MCU will then receive media from all other participa= nts, do voice activation, and forward the media streams with the "current s= peaker", "recenve-1" etc to me. How the other endpoints provide their media to the MCU, and what roles are = used, is a separate story. Regards, Christer From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 7. maaliskuuta 2013 14:52 To: Christer Holmberg; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, I will try to understand. What you are saying that we will have, for exampl= e, three media captures, "current speaker","recent-1" and "recent-2". This = will be used for MCU that does voice activation video switching but sends m= ore than one RTP stream to each receiver. Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 2:28 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >I think that if we use CLUE to signal the active speaker, previous, Etc it= will require many messages since the speakers change. I am not sure I understand. The idea is to have a MCU capture, and e.g. a s= ingle stream, and the MCU switches the content based on who is active. Ther= e is no need to re-negotiate anything. Or, what messages do you refer to? >The information who is speaking can be available from the CSRC or using th= e RTP header extension level attributes. RFC6465 provides the use case you = discuss. I am not talking about WHO (as in whether it's Alice, Bob or Carol) is talk= ing, but that whoever is talking is provided from the MCU capture. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 1:32 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >This is a point I made in the past that for switched capture it may be goo= d to know what is the policy, can be active speaker, time switch (round rob= in) or other methods. Correct. So, the question is whether that policy can be seen as a "role". There could also be "2nd recent speaker", "3rd recent speaker" etc, but ins= tead of defining a separate role for each of them, maybe we could have an a= ttribute value, e.g. "recent-speaker=3D2". This type of functionality is very important for devices with a limited num= ber of streams, screens etc - it non-telepresence rooms. >As for your second question advertisement is what can be sent, you probabl= y meant that the configure message should allow to select a specific switch= policy, I think that the configure can only ask for something that was adv= ertised Yes. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and = provides the active speaker to a single screen entity. So, the content will= change as the most active changes, but the capture provided by the MCU wil= l be the same. So, the "role" of this capture would be "active speaker". Or? Q2. I assume that capture attribute can also be used during the advertisement p= hase. Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the "active speaker" role. Or? Regards, Christer --_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68B682xmbrcdx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I sugge= st we split the problem into two parts.

= 1)      Subscribe to virtual captures, allow to server to forward based on informa= tion available on the server. The most normal scenario is to forward based = on audio activity.

= 2)      Setting policy for how the server should switch streams. Policies could be

a.       Active speaker (based on audio level) 

b.      Round robin

&n= bsp;

A clien= t could then request two virtual streams (with capture id 1 and 2) with pol= icy ‘active speaker’, that should mean that the two loudest spe= aker should be in either capture id 1 or 2, to avoid having the capture id changing.

&n= bsp;

-Espen =

&n= bsp;

&n= bsp;

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 7. mars 2013 14:14
To: Roni Even; clue@ietf.org
Subject: Re: [clue] Active speaker a role?

 

Hi,

&n= bsp;

The MCU= will advertise, to me, that it can provide three media captures (as in you= r example). The MCU will then receive media from all other participants, do= voice activation, and forward the media streams with the “current speaker”, “recenve-1” et= c to me.

&n= bsp;

How the= other endpoints provide their media to the MCU, and what roles are used, i= s a separate story.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

From: Roni Even [= mailto:ron.even.tlv@gmail.com]
Sent: 7. maaliskuuta 2013 14:52
To: Christer Holmberg; clue@ietf.or= g
Subject: RE: [clue] Active speaker a role?

 

Hi,

I will = try to understand. What you are saying that we will have, for example, thre= e media captures, “current speaker”,”recent-1” and = “recent-2”. This will be used for MCU that does voice activatio= n video switching but sends more than one RTP stream to each receiver.<= /o:p>

Roni

&n= bsp;

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 07 March, 2013 2:28 PM
To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role?

 

Hi,

&n= bsp;

>I t= hink that if we use CLUE to signal the active speaker, previous, Etc it wil= l require many messages since the speakers change.

&n= bsp;

I am no= t sure I understand. The idea is to have a MCU capture, and e.g. a single s= tream, and the MCU switches the content based on who is active. There is no= need to re-negotiate anything. Or, what messages do you refer to?

&n= bsp;

>The= information who is speaking can be available from the CSRC or using the RT= P header extension level attributes. RFC6465 provides the use case you disc= uss.

&n= bsp;

I am no= t talking about WHO (as in whether it’s Alice, Bob or Carol) is talki= ng, but that whoever is talking is provided from the MCU capture.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: 07 March, 2013 1:32 PM
To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role?

 

Hi,

&n= bsp;

>Thi= s is a point I made in the past that for switched capture it may be good to= know what is the policy, can be active speaker, time switch (round robin) = or other methods.

&n= bsp;

Correct= . So, the question is whether that policy can be seen as a “role̶= 1;.

&n= bsp;

There c= ould also be “2nd recent speaker”, “3rd recent speaker” etc, but instead of defining a separate role for= each of them, maybe we could have an attribute value, e.g. “recent-s= peaker=3D2”.

&n= bsp;

This ty= pe of functionality is very important for devices with a limited number of = streams, screens etc – it non-telepresence rooms.

&n= bsp;

>As = for your second question advertisement is what can be sent, you probably me= ant that the configure message should allow to select a specific switch pol= icy, I think that the configure can only ask for something that was advertised

&n= bsp;

Yes.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

&n= bsp;

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 07 March, 2013 10:19 AM
To: clue@ietf.org
Subject: [clue] Active speaker a role?

 

Hi,

 

A couple of questions related t= o the capture attribute draft.

 

Q1.

 

Assume you have a MCU, which co= llects streams from multiple endpoints, and provides the active speaker to = a single screen entity. So, the content will change as the most active chan= ges, but the capture provided by the MCU will be the same.

 

So, the “role” of t= his capture would be “active speaker”. Or?

 

 

Q2.

 

I assume that capture attribute= can also be used during the advertisement phase. Ie a single entity can in= dicate that it is able to receive a stream, where it want the content to be= the “active speaker” role. Or?

 

 

Regards,

 

Christer

 

--_000_E8F5F2C7B2623641BD9ABF0B622D726D0F68B682xmbrcdx11ciscoc_-- From mary.ietf.barnes@gmail.com Thu Mar 7 10:49:16 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 41D8021F8A3E for ; Thu, 7 Mar 2013 10:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.723 X-Spam-Level: X-Spam-Status: No, score=-103.723 tagged_above=-999 required=5 tests=[AWL=-0.124, 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 kyZPaXnRrLRj for ; Thu, 7 Mar 2013 10:49:15 -0800 (PST) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 607EF21F89DC for ; Thu, 7 Mar 2013 10:49:15 -0800 (PST) Received: by mail-qa0-f44.google.com with SMTP id bv4so3452431qab.10 for ; Thu, 07 Mar 2013 10:49:15 -0800 (PST) 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:cc:content-type; bh=+4LA0HFLcrH6CQmm6BdLNs40UZfWWfzQJ9b09CHtJ48=; b=k8RrCW33I3yvJjLDUAYa/TaOm27ILWluB1zV2y6GbjJIp9AcX/UF71TZNuOCwzzAJQ LGjBVI6dNR/7K76sXNos6d4VI+5h43GW8mFWqmOdHpikq7vj0ZYNfrfmm1XFrHwOQMJY 259SHezOZgGy39GOyENUmhs7Cg+CBmyFD4gfEdmwuxnGN3mET5gW9mUCxcUBMzYvfu2u lbzIRWUaX1noE4DcAhBKGJT0CVyjok9n/WxYx48KPOnhbVSwq67ux1SeuCC9ed+jaUC5 2TROqgMbHzm5/yoGfH83SpVjZzzQSpln2buncjpg/miTdsxerzoyJERddJFYIzux+zxB laVw== MIME-Version: 1.0 X-Received: by 10.224.216.65 with SMTP id hh1mr51135696qab.43.1362682154916; Thu, 07 Mar 2013 10:49:14 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 10:49:14 -0800 (PST) In-Reply-To: References: Date: Thu, 7 Mar 2013 12:49:14 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 18:49:16 -0000 Also (and more relevant to CLUE), please keep in mind that Rob's draft gets very much into this topic as to the split between CLUE and SDP as well as advantages/disadvantages: http://datatracker.ietf.org/doc/draft-hansen-clue-sdp-interaction/ We will discuss this in our first session on Monday. Thanks, Mary. On Thu, Mar 7, 2013 at 12:08 PM, Mary Barnes wrote: > I really think CLUE folks need to read this thread and understand the issues: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html > > While we aren't defining an API, we are defining a application. I > think it's important to carefully consider the tradeoffs in terms of > how much is carried in SDP versus how much we can do with a CLUE > specific protocol. > > > I really, really think that the more we put in SDP, the less > extensibility we will have for the CLUE application - I think we > really, really need to carefully weigh the tradeoffs between tightly > coupling the CLUE application to SDP versus minimizing the > interactions and duplication of information. > > In one sense, this is a similar problem we faced with SIP > conferencing. We defined some basic extensions that worked just fine. > But, it would have been a bear to add all the additional functionality > for complex scenarios to SIP. Instead, we defined XCON, which > decouples the conferencing application from the session > setup/signaling protocol. XCON is highly extensible and flexible and > provides a rich set of application functionality. I believe we want > to same with CLUE a > > > > Mary. From pkyzivat@alum.mit.edu Thu Mar 7 11:12:14 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 3B6B121F8B20 for ; Thu, 7 Mar 2013 11:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.082 X-Spam-Level: X-Spam-Status: No, score=0.082 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=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 3pxNrMqiAhhH for ; Thu, 7 Mar 2013 11:12:13 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6596121F8B1A for ; Thu, 7 Mar 2013 11:12:13 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8bHm1l00C0ldTLk53jCCDN; Thu, 07 Mar 2013 19:12:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id 8jCC1l00r3ZTu2S3QjCCAN; Thu, 07 Mar 2013 19:12:12 +0000 Message-ID: <5138E68B.5000003@alum.mit.edu> Date: Fri, 08 Mar 2013 03:12:11 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: 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=1362683532; bh=uiGdbr12UGs5XEDO7y4KUaTaJ94ZnTbu7f4dfsitrc0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=omaIUXlmOs/L2AxLpQFRkhjGvkH7jpUZa9v+ZeYWUKg9O/zT831ToKdg+EKlz+jZ7 duDa7I4URbVEGJSrnUOlryPFo6XIkHVCu/GisgIvzq/zwhuOnCscx1WRvryvz/7Pd6 eU091tO23fPkpHnuzn6hGBrkIbqjeo1NjC1uoZ1nVxgdwEJ3F3sLLi+1ZpmpjL4JdG VVl8C2YA7J2g+xrPPW43AvXUsceMXQIcTCGknuA6X9c7/Dlal9yX7FhRdjim9PPoZ3 LbReRh5UDw09Eo9NIreEt7/y0xF3jkT4l0+UGZoAjCeXYTFWIuvozs0oRuC/0be1Cq dG5zdfRQRX0sg== Cc: CLUE Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 19:12:14 -0000 I don't fully agree with Mary on this. First, I don't think that discussion in RTCWEB has much bearing on CLUE. RTCWEB uses a non-sip signaling model. And it doesn't even call for use of SDP in signaling. Rather it only uses SDP for communication between the javascript and the browser it runs in. It doesn't require that the SDP constructed in one broswer be identical to that seen in the browser at the other end. SDP has long been a poor choice for the purpose we use it, but we have legacy reasons to continue and efforts to move to SDPng failed. It is extremely poor as an abstract conceptual representation for an API. So IMO it makes sense to think hard about whether to use it in RTCWEB. The argument there is not what to put in SDP and what to do another way, it is about whether to use SDP or not. But CLUE is mostly SIP-based. We are going to be using SDP. For us the question is how much to put in SDP and how much to put in the CLUE protocol. I don't think the rtcweb arguments are helpful about that. IMO we should use SDP for the things it does, and perhaps extend it a bit for things it *ought* to do, philosophically. SDP O/A is focused on two ends negotiating based on what each is prepared to receive. Sometimes it talks about what is to be sent, but it isn't so good about that. In the end the result of the negotiation defines characteristics of what *will* be sent. And that part is important to some middle boxes, so we should try hard not to break that. Clue is focused on presenting a menu of what *could* be *sent* and then selecting from that menu what should be sent, and how. It is pretty hard to work out what SDP is required until all that is known. So I prefer keeping the division that way - the SDP is only used to signal the details to support what will be sent, based on what was agreed in the clue signaling. In some cases this may lead to conflicts. For instance, SDP has the a=content attribute. In our clue data model and signaling we will have a much richer mechanism to describe similar characteristics. IMO we should not feel a need to exclusively use SDP for this. I don't know that we need to use it at all between clue-aware endpoints, though we ought to do as much as we can when talking to legacy endpoints. So in practice I will probably agree with Mary most of the time about what should be in SDP and what should not. I'll also observe that the less we depend on SDP the less trouble we will have making CLUE work in RTCWEB. Thanks, Paul On 3/8/13 2:08 AM, Mary Barnes wrote: > I really think CLUE folks need to read this thread and understand the issues: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html > > While we aren't defining an API, we are defining a application. I > think it's important to carefully consider the tradeoffs in terms of > how much is carried in SDP versus how much we can do with a CLUE > specific protocol. > > > I really, really think that the more we put in SDP, the less > extensibility we will have for the CLUE application - I think we > really, really need to carefully weigh the tradeoffs between tightly > coupling the CLUE application to SDP versus minimizing the > interactions and duplication of information. > > In one sense, this is a similar problem we faced with SIP > conferencing. We defined some basic extensions that worked just fine. > But, it would have been a bear to add all the additional functionality > for complex scenarios to SIP. Instead, we defined XCON, which > decouples the conferencing application from the session > setup/signaling protocol. XCON is highly extensible and flexible and > provides a rich set of application functionality. I believe we want > to same with CLUE a > > > > Mary. > From mary.ietf.barnes@gmail.com Thu Mar 7 11:16: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 EFA5F21F8C59 for ; Thu, 7 Mar 2013 11:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.416 X-Spam-Level: X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 L98PEEpOc1Zb for ; Thu, 7 Mar 2013 11:16:21 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 80B4921F8C46 for ; Thu, 7 Mar 2013 11:16:21 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id cz11so501281qeb.26 for ; Thu, 07 Mar 2013 11:16:21 -0800 (PST) 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:cc:content-type; bh=m5oBw1oeXjD1EWXTgXM6FOWZsWDAEdHsghVRzQOzJ3Y=; b=s7Ty3IceW8SHol/X2Vdv698YAz25L1sDCRhz+fcmU49YpVsb5Hk80m99TkpVyV5g8h +LL7sIu7aNDeRKQKynaVZnclT5AzBJuVoMRyHtAx/cBR8oKJq6OfvPaF7xJMCw2C6RQp xhQLmtkWFqevtuRu6TnopvmGDN7eEQxm1Ys+n+jQApW6Li4Tm7UCHJPtUj0vYAYniGpt J4Gbpr8RQhTh2xAjS9m2+w4vQYOfWovfPWCV3mhwnuyo0R/LhWbaBLXaxtc8TuxdTwGS 1BCqUUZUjfiWspe/uynKZOTJDMpQYnKkwoTpKSTzCcSQgt5l+G+v7k32aWWB/SN2fzol W7NA== MIME-Version: 1.0 X-Received: by 10.49.61.164 with SMTP id q4mr32311046qer.60.1362683781000; Thu, 07 Mar 2013 11:16:21 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 11:16:20 -0800 (PST) In-Reply-To: <5138E68B.5000003@alum.mit.edu> References: <5138E68B.5000003@alum.mit.edu> Date: Thu, 7 Mar 2013 13:16:20 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 19:16:23 -0000 On Thu, Mar 7, 2013 at 1:12 PM, Paul Kyzivat wrote: > I don't fully agree with Mary on this. [MB] As an individual and not as a chair I am hoping ;) [/MB] > > First, I don't think that discussion in RTCWEB has much bearing on CLUE. > RTCWEB uses a non-sip signaling model. And it doesn't even call for use of > SDP in signaling. Rather it only uses SDP for communication between the > javascript and the browser it runs in. It doesn't require that the SDP > constructed in one broswer be identical to that seen in the browser at the > other end. SDP has long been a poor choice for the purpose we use it, but we > have legacy reasons to continue and efforts to move to SDPng failed. It is > extremely poor as an abstract conceptual representation for an API. So IMO > it makes sense to think hard about whether to use it in RTCWEB. The argument > there is not what to put in SDP and what to do another way, it is about > whether to use SDP or not. > > But CLUE is mostly SIP-based. We are going to be using SDP. For us the > question is how much to put in SDP and how much to put in the CLUE protocol. > I don't think the rtcweb arguments are helpful about that. > > IMO we should use SDP for the things it does, and perhaps extend it a bit > for things it *ought* to do, philosophically. SDP O/A is focused on two ends > negotiating based on what each is prepared to receive. Sometimes it talks > about what is to be sent, but it isn't so good about that. In the end the > result of the negotiation defines characteristics of what *will* be sent. > And that part is important to some middle boxes, so we should try hard not > to break that. > > Clue is focused on presenting a menu of what *could* be *sent* and then > selecting from that menu what should be sent, and how. It is pretty hard to > work out what SDP is required until all that is known. So I prefer keeping > the division that way - the SDP is only used to signal the details to > support what will be sent, based on what was agreed in the clue signaling. > > In some cases this may lead to conflicts. For instance, SDP has the > a=content attribute. In our clue data model and signaling we will have a > much richer mechanism to describe similar characteristics. IMO we should not > feel a need to exclusively use SDP for this. I don't know that we need to > use it at all between clue-aware endpoints, though we ought to do as much as > we can when talking to legacy endpoints. > > So in practice I will probably agree with Mary most of the time about what > should be in SDP and what should not. > > I'll also observe that the less we depend on SDP the less trouble we will > have making CLUE work in RTCWEB. [MB] Yes - I totally agree. [/MB] > > Thanks, > Paul > > > On 3/8/13 2:08 AM, Mary Barnes wrote: >> >> I really think CLUE folks need to read this thread and understand the >> issues: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html >> >> While we aren't defining an API, we are defining a application. I >> think it's important to carefully consider the tradeoffs in terms of >> how much is carried in SDP versus how much we can do with a CLUE >> specific protocol. >> >> >> I really, really think that the more we put in SDP, the less >> extensibility we will have for the CLUE application - I think we >> really, really need to carefully weigh the tradeoffs between tightly >> coupling the CLUE application to SDP versus minimizing the >> interactions and duplication of information. >> >> In one sense, this is a similar problem we faced with SIP >> conferencing. We defined some basic extensions that worked just fine. >> But, it would have been a bear to add all the additional functionality >> for complex scenarios to SIP. Instead, we defined XCON, which >> decouples the conferencing application from the session >> setup/signaling protocol. XCON is highly extensible and flexible and >> provides a rich set of application functionality. I believe we want >> to same with CLUE a >> >> >> >> Mary. >> > From christer.holmberg@ericsson.com Thu Mar 7 11:39: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 C23DD21F852A for ; Thu, 7 Mar 2013 11:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1QwjEn46jaP for ; Thu, 7 Mar 2013 11:39:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE3421F89AE for ; Thu, 7 Mar 2013 11:39:41 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-eb-5138ecfc2408 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 45.01.10459.CFCE8315; Thu, 7 Mar 2013 20:39:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 20:39:40 +0100 From: Christer Holmberg To: Paul Kyzivat , Mary Barnes Thread-Topic: [clue] RTCWEB: using SDP "blob" and O/A model Thread-Index: AQHOG17DzKsmp6k6zUOYsE+3oQfPwZiah9WAgAAWwfw= Date: Thu, 7 Mar 2013 19:39:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> References: , <5138E68B.5000003@alum.mit.edu> In-Reply-To: <5138E68B.5000003@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje6fNxaBBo3btS32n7rMbPF5/35m ixUbDrA6MHv8ff+ByWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyri75wpjwWTVigVtT1kb GE/KdjFyckgImEhs7DjBCmGLSVy4t56ti5GLQ0jgEKPErtYuRghnEaPEiy1vmLoYOTjYBCwk uv9pgzSICIRItFxqZAOxmQUkJFZd/MAIUiIsYCXxeV4sRIm1RHP/BiYI20pi/d0Z7CA2i4CK xPYnV1hBynkFvCWe/C0HCQsJFEic3HcVrJxTQEfi/6p9YNMZgU77fmoNE8QmcYlbT+YzQZws ILFkz3lmCFtU4uXjf1CvKEq0P21ghKjXkViw+xPUldoSyxa+BqvnFRCUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjGy5yZm5qSXG25iBMbMwS2/dXcwnjoncohRmoNFSZw3zPVCgJBAemJJ anZqakFqUXxRaU5q8SFGJg5OqQZG5jcvdhmmPf+WW1ce/HPjxKOJMXMXy8gZWSmvd1RfXLDL LXFiieMkxTvsdianwmKNNlauW/dI123esaiyu4Yb7kvdzClykP+pGpdb93TV3L97Yj6XV2k3 91feysld83Ar2x87WYfE/oO9Ivk2Lt3uC4SLN4f+/5GeEvpsXdj8ni4jk4d/RLyVWIozEg21 mIuKEwFbXQUrZwIAAA== Cc: CLUE Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 19:39:42 -0000 Hi, I agree with Paul. My personal starting point is still that the CLUE signalling should be used= for the telepresence application related stuff, like spatial relationship = etc. I also don't think that the RTCWEB outcome affect us, as far as our mechani= sm is concerned. However, if RTCWEB loses interest in pushing for SDP and/o= r RTP extensions that we also are interested in, WE may have to become more= active in that work. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Thursday, 07 March 2013 9:12 PM To: Mary Barnes Cc: CLUE Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model I don't fully agree with Mary on this. First, I don't think that discussion in RTCWEB has much bearing on CLUE. RTCWEB uses a non-sip signaling model. And it doesn't even call for use of SDP in signaling. Rather it only uses SDP for communication between the javascript and the browser it runs in. It doesn't require that the SDP constructed in one broswer be identical to that seen in the browser at the other end. SDP has long been a poor choice for the purpose we use it, but we have legacy reasons to continue and efforts to move to SDPng failed. It is extremely poor as an abstract conceptual representation for an API. So IMO it makes sense to think hard about whether to use it in RTCWEB. The argument there is not what to put in SDP and what to do another way, it is about whether to use SDP or not. But CLUE is mostly SIP-based. We are going to be using SDP. For us the question is how much to put in SDP and how much to put in the CLUE protocol. I don't think the rtcweb arguments are helpful about that. IMO we should use SDP for the things it does, and perhaps extend it a bit for things it *ought* to do, philosophically. SDP O/A is focused on two ends negotiating based on what each is prepared to receive. Sometimes it talks about what is to be sent, but it isn't so good about that. In the end the result of the negotiation defines characteristics of what *will* be sent. And that part is important to some middle boxes, so we should try hard not to break that. Clue is focused on presenting a menu of what *could* be *sent* and then selecting from that menu what should be sent, and how. It is pretty hard to work out what SDP is required until all that is known. So I prefer keeping the division that way - the SDP is only used to signal the details to support what will be sent, based on what was agreed in the clue signaling. In some cases this may lead to conflicts. For instance, SDP has the a=3Dcontent attribute. In our clue data model and signaling we will have a much richer mechanism to describe similar characteristics. IMO we should not feel a need to exclusively use SDP for this. I don't know that we need to use it at all between clue-aware endpoints, though we ought to do as much as we can when talking to legacy endpoints. So in practice I will probably agree with Mary most of the time about what should be in SDP and what should not. I'll also observe that the less we depend on SDP the less trouble we will have making CLUE work in RTCWEB. Thanks, Paul On 3/8/13 2:08 AM, Mary Barnes wrote: > I really think CLUE folks need to read this thread and understand the iss= ues: > http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html > > While we aren't defining an API, we are defining a application. I > think it's important to carefully consider the tradeoffs in terms of > how much is carried in SDP versus how much we can do with a CLUE > specific protocol. > > > I really, really think that the more we put in SDP, the less > extensibility we will have for the CLUE application - I think we > really, really need to carefully weigh the tradeoffs between tightly > coupling the CLUE application to SDP versus minimizing the > interactions and duplication of information. > > In one sense, this is a similar problem we faced with SIP > conferencing. We defined some basic extensions that worked just fine. > But, it would have been a bear to add all the additional functionality > for complex scenarios to SIP. Instead, we defined XCON, which > decouples the conferencing application from the session > setup/signaling protocol. XCON is highly extensible and flexible and > provides a rich set of application functionality. I believe we want > to same with CLUE a > > > > Mary. > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Thu Mar 7 11:48:13 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 03B8921F8B1C for ; Thu, 7 Mar 2013 11:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.231 X-Spam-Level: X-Spam-Status: No, score=-6.231 tagged_above=-999 required=5 tests=[AWL=0.018, 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 3f2m8wz-36-9 for ; Thu, 7 Mar 2013 11:48:12 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0A721F8AB8 for ; Thu, 7 Mar 2013 11:48:11 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-98-5138eefa0bc0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id CF.49.19728.AFEE8315; Thu, 7 Mar 2013 20:48:10 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 20:48:09 +0100 From: Christer Holmberg To: "Espen Berger (espeberg)" , Roni Even , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkP//+iSA///ET0CAAHOcgP//7D3ggAAeSYD//+nn8AAOqeeAAASb+fw= Date: Thu, 7 Mar 2013 19:48:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B116249@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> <061501ce1b32$91608660$b4219320$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B6A@ESESSMB209.ericsson.se>, 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.19] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+Jvje6vdxaBBtd3K1nsP3WZ2eJLQ7LF 33ZmB2aPKb83snrsnHWX3WPJkp9MAcxRXDYpqTmZZalF+nYJXBmfV6xnLtioXjFhyzfmBsYd 8l2MnBwSAiYSh2ffYoOwxSQu3FsPZHNxCAkcYpTY2bSYGcJZxCjxY9tXxi5GDg42AQuJ7n/a IA0iApUSK//MZwSxhQW0JA7d/sgGEdeW6P/7iRnCTpLYPX0KO0gri4CKRO8URZAwr4C3xMs/ 81ghxt9hlmhf8okdJMEp4Cvx98dtMJsR6KDvp9YwgdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTL x/9YIWxFifanDYwQ9QYS78/NZ4awtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxg ZFnFyJ6bmJmTXm60iREYGwe3/FbdwXjnnMghRmkOFiVx3nDXCwFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGOd3dUWtc1EKK9odptMYuV3Y/8iz9V/cn7Rf006ZM0k5aVPEp/zJvcLMopPY hFfvsDmq0X/0xL1wVbHpR0LuvFrYaifouPBSocvaJkZ796zOh/m1ytyswvZ2a+bdOl98R+uW qMG7WKnVSm4S3s+Z9GfrzrTacn6nfPeMafM/+JSy5pWVMy/YosRSnJFoqMVcVJwIAGPKfQlb AgAA Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 19:48:13 -0000 Hi, >I suggest we split the problem into two parts. > >1) Subscribe to virtual captures, allow to server to forward based on= information available on the server. The most normal scenario is to forwar= d based on audio activity. > >2) Setting policy for how the server should switch streams. Policies = could be > >a. Active speaker (based on audio level) > >b. Round robin > >A client could then request two virtual streams (with capture id 1 and 2) = with policy =91active speaker=92, that should mean that the two loudest spe= aker should be in either capture id 1 or 2, to avoid having the capture id = changing. I don't think the the active speaker should change between virtual captures= - I'd rather see one virtual capture with the "active speaker" role.=20 Because, I might negotiate a HD quality stream for the capture associated w= ith the active speaker, while I request thumbnail quality stream(s) for oth= er participant(s). Regards, Christer From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: 7. mars 2013 14:14 To: Roni Even; clue@ietf.org Subject: Re: [clue] Active speaker a role? Hi, The MCU will advertise, to me, that it can provide three media captures (as= in your example). The MCU will then receive media from all other participa= nts, do voice activation, and forward the media streams with the =93current= speaker=94, =93recenve-1=94 etc to me. How the other endpoints provide their media to the MCU, and what roles are = used, is a separate story. Regards, Christer From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 7. maaliskuuta 2013 14:52 To: Christer Holmberg; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, I will try to understand. What you are saying that we will have, for exampl= e, three media captures, =93current speaker=94,=94recent-1=94 and =93recent= -2=94. This will be used for MCU that does voice activation video switching= but sends more than one RTP stream to each receiver. Roni From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 2:28 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >I think that if we use CLUE to signal the active speaker, previous, Etc it= will require many messages since the speakers change. I am not sure I understand. The idea is to have a MCU capture, and e.g. a s= ingle stream, and the MCU switches the content based on who is active. Ther= e is no need to re-negotiate anything. Or, what messages do you refer to? >The information who is speaking can be available from the CSRC or using th= e RTP header extension level attributes. RFC6465 provides the use case you = discuss. I am not talking about WHO (as in whether it=92s Alice, Bob or Carol) is ta= lking, but that whoever is talking is provided from the MCU capture. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 March, 2013 1:32 PM To: Roni Even; clue@ietf.org Subject: RE: [clue] Active speaker a role? Hi, >This is a point I made in the past that for switched capture it may be goo= d to know what is the policy, can be active speaker, time switch (round rob= in) or other methods. Correct. So, the question is whether that policy can be seen as a =93role= =94. There could also be =932nd recent speaker=94, =933rd recent speaker=94 etc,= but instead of defining a separate role for each of them, maybe we could h= ave an attribute value, e.g. =93recent-speaker=3D2=94. This type of functionality is very important for devices with a limited num= ber of streams, screens etc =96 it non-telepresence rooms. >As for your second question advertisement is what can be sent, you probabl= y meant that the configure message should allow to select a specific switch= policy, I think that the configure can only ask for something that was adv= ertised Yes. Regards, Christer From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Christer Holmberg Sent: 07 March, 2013 10:19 AM To: clue@ietf.org Subject: [clue] Active speaker a role? Hi, A couple of questions related to the capture attribute draft. Q1. Assume you have a MCU, which collects streams from multiple endpoints, and = provides the active speaker to a single screen entity. So, the content will= change as the most active changes, but the capture provided by the MCU wil= l be the same. So, the =93role=94 of this capture would be =93active speaker=94. Or? Q2. I assume that capture attribute can also be used during the advertisement p= hase. Ie a single entity can indicate that it is able to receive a stream, = where it want the content to be the =93active speaker=94 role. Or? Regards, Christer From mary.ietf.barnes@gmail.com Thu Mar 7 11:48: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 020CD21F8B1C for ; Thu, 7 Mar 2013 11:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, J_CHICKENPOX_17=0.6, 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 mMc-oONFajQC for ; Thu, 7 Mar 2013 11:48:49 -0800 (PST) Received: from mail-qe0-f43.google.com (mail-qe0-f43.google.com [209.85.128.43]) by ietfa.amsl.com (Postfix) with ESMTP id DD5D321F8BED for ; Thu, 7 Mar 2013 11:48:48 -0800 (PST) Received: by mail-qe0-f43.google.com with SMTP id 1so524771qee.2 for ; Thu, 07 Mar 2013 11:48:48 -0800 (PST) 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:cc:content-type; bh=3JT+QXmK1NjFZvZ9KyftyVNYV6EPV+BEsoSEBEVTgBM=; b=suDbXT+Ii+AKK2DP1p0nZgwf6jrcQ+FfGiIC/D8/pmsLd+OEgHpXJJD2cw1NPt3yPT 6FdUDVJr2hBdGU9V8BENeN/IwUNMLknMFjdww//CTEiuExoUMbEchbW/FbHfOidEPxNl oAmq/fcNy7dFbgQIoFQPBLlGCeiBsi+/tC8WSucxomheYvIaL8FOqtcnoBdqV2n7YuN3 bV6wTIwDcz6m7gEg1a+aLpx0zAXdajoEXju6DNkQFiuECBkNI1HcfzFDB5O5BxfCBNvH yCiHk7TIqDRILJT74k2Q963xfX4RIFvOLZKetvii0LFmwOtVyWwYvmLfijc+mzE6jX7f wsIg== MIME-Version: 1.0 X-Received: by 10.224.191.68 with SMTP id dl4mr5100963qab.85.1362685728365; Thu, 07 Mar 2013 11:48:48 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 11:48:48 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> Date: Thu, 7 Mar 2013 13:48:48 -0600 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 19:48:50 -0000 On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg wrote: > > Hi, > > I agree with Paul. > > My personal starting point is still that the CLUE signalling should be used for the telepresence application related stuff, like spatial relationship etc. > > I also don't think that the RTCWEB outcome affect us, as far as our mechanism is concerned. However, if RTCWEB loses interest in pushing for SDP and/or RTP extensions that we also are interested in, WE may have to become more active in that work. [MB] I wasn't suggesting that their decision as to the mechanism would directly impact CLUE. I'm suggesting that some of the challenges they are having are due to the fact that they are trying to use SDP for something that it really wasn't designed or envisioned to be used for. I do believe that some of the issues with SDP that they are encountering that is making folks rethink the RTCWEB decision are not unlike those that CLUE may have to deal with. I strongly believe that decoupling the CLUE application from SDP as much as possible is a better path than trying to put so much into SDP (which is a *similar* discussion as is happening in RTCWEB in terms of decoupling the API from SDP). I understand that we are using SIP for session setup, so of course, we will need to use SDP O/A and thus we can't totally decouple. As we have been discussing for well over a year, the challenge is how much of the CLUE application information should be carried in SDP versus a CLUE specific protocol. We should already be more active in the work and not expect that we would just use what RTCWEB needs. CLUE requirements should be considered equal to those of RTCWEB. I think we also need to be very thoughtful as to how we make our decisions so we don't end up a year from now with folks questioning the path we chose. > > Regards, > > Christer > > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Thursday, 07 March 2013 9:12 PM > To: Mary Barnes > Cc: CLUE > Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model > > I don't fully agree with Mary on this. > > First, I don't think that discussion in RTCWEB has much bearing on CLUE. > RTCWEB uses a non-sip signaling model. And it doesn't even call for use > of SDP in signaling. Rather it only uses SDP for communication between > the javascript and the browser it runs in. It doesn't require that the > SDP constructed in one broswer be identical to that seen in the browser > at the other end. SDP has long been a poor choice for the purpose we use > it, but we have legacy reasons to continue and efforts to move to SDPng > failed. It is extremely poor as an abstract conceptual representation > for an API. So IMO it makes sense to think hard about whether to use it > in RTCWEB. The argument there is not what to put in SDP and what to do > another way, it is about whether to use SDP or not. > > But CLUE is mostly SIP-based. We are going to be using SDP. For us the > question is how much to put in SDP and how much to put in the CLUE > protocol. I don't think the rtcweb arguments are helpful about that. > > IMO we should use SDP for the things it does, and perhaps extend it a > bit for things it *ought* to do, philosophically. SDP O/A is focused on > two ends negotiating based on what each is prepared to receive. > Sometimes it talks about what is to be sent, but it isn't so good about > that. In the end the result of the negotiation defines characteristics > of what *will* be sent. And that part is important to some middle boxes, > so we should try hard not to break that. > > Clue is focused on presenting a menu of what *could* be *sent* and then > selecting from that menu what should be sent, and how. It is pretty hard > to work out what SDP is required until all that is known. So I prefer > keeping the division that way - the SDP is only used to signal the > details to support what will be sent, based on what was agreed in the > clue signaling. > > In some cases this may lead to conflicts. For instance, SDP has the > a=content attribute. In our clue data model and signaling we will have a > much richer mechanism to describe similar characteristics. IMO we should > not feel a need to exclusively use SDP for this. I don't know that we > need to use it at all between clue-aware endpoints, though we ought to > do as much as we can when talking to legacy endpoints. > > So in practice I will probably agree with Mary most of the time about > what should be in SDP and what should not. > > I'll also observe that the less we depend on SDP the less trouble we > will have making CLUE work in RTCWEB. > > Thanks, > Paul > > On 3/8/13 2:08 AM, Mary Barnes wrote: >> I really think CLUE folks need to read this thread and understand the issues: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html >> >> While we aren't defining an API, we are defining a application. I >> think it's important to carefully consider the tradeoffs in terms of >> how much is carried in SDP versus how much we can do with a CLUE >> specific protocol. >> >> >> I really, really think that the more we put in SDP, the less >> extensibility we will have for the CLUE application - I think we >> really, really need to carefully weigh the tradeoffs between tightly >> coupling the CLUE application to SDP versus minimizing the >> interactions and duplication of information. >> >> In one sense, this is a similar problem we faced with SIP >> conferencing. We defined some basic extensions that worked just fine. >> But, it would have been a bear to add all the additional functionality >> for complex scenarios to SIP. Instead, we defined XCON, which >> decouples the conferencing application from the session >> setup/signaling protocol. XCON is highly extensible and flexible and >> provides a rich set of application functionality. I believe we want >> to same with CLUE a >> >> >> >> Mary. >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Thu Mar 7 11:57: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 E88D621F8ABC for ; Thu, 7 Mar 2013 11:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.694 X-Spam-Level: X-Spam-Status: No, score=-103.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 mfXcVgPTjLNg for ; Thu, 7 Mar 2013 11:57:23 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 3D08521F8AA6 for ; Thu, 7 Mar 2013 11:57:23 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id cr7so3492933qab.1 for ; Thu, 07 Mar 2013 11:57:22 -0800 (PST) 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 :content-type; bh=Jx1fPBYsytd8aM7JupmKtyPDqonQxZbYUhuPY3Yf104=; b=Qkz5d4xmBluKtnUXpR64RG3COdk2xGVe6FnsmZByMfyW9G8om/y+zwphpGKYIInBwE Bh8B9lc2k54Lo1brri3NlzeU8ahwtFV3sDPZ2ORQU52WbcrEQDHdxtRL2cuCzg/Vyn6F DJ6XXHY119W5jV/PL7s+yzOTjb22y/xdixeyUSKXObbkZYC1kgzx9ymEmG/2zLr6X31u GIXlX/LeZnoUkSk0B+9fU3Y6qN9UAI5uQp6W6zBpY8xfEwN+F2dNVcx0Dsps6jlFR+wR P5CnSidt56BKEzDL+W8LSW3LLn7AwFG8KkShDvMqUKu5OiWOVBHH8ehHl1Tf+i7XwZz6 q74Q== MIME-Version: 1.0 X-Received: by 10.229.136.69 with SMTP id q5mr11995745qct.108.1362686242784; Thu, 07 Mar 2013 11:57:22 -0800 (PST) Received: by 10.49.24.130 with HTTP; Thu, 7 Mar 2013 11:57:22 -0800 (PST) Date: Thu, 7 Mar 2013 13:57:22 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Just an FYI: Another analysis of SDP/RTCWEB 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, 07 Mar 2013 19:57:24 -0000 Here's another blog post that discusses the RTCWEB/SDP issues. I still believe some of this discussion is quite relevant - I *love* the photo: http://blog.webrtc.is/2013/02/26/sdp-in-webrtc-who-cares/ Just as it was discussed on the RTCWEB list, many of the SDP proponents are wanting to protect current products. That was the reason that SDPNG was abandoned. And, certainly, that can be deemed a fairly strong argument as it appears that it might at first appear to require more work not to reuse SDP as much as possible. However, I would contend that the interop challenge and changes required to SDP code will be more expensive in the long run than a solution that minimizes the dependency on SDP. Mary. From pkyzivat@alum.mit.edu Thu Mar 7 12:00:24 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 4472921F8B27 for ; Thu, 7 Mar 2013 12:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=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 YVDzyYxmdY24 for ; Thu, 7 Mar 2013 12:00:21 -0800 (PST) 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 1C6B221F8C20 for ; Thu, 7 Mar 2013 12:00:20 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id 8jXD1l00216LCl05Ck0LuL; Thu, 07 Mar 2013 20:00:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 8k0K1l01Q3ZTu2S3Sk0L00; Thu, 07 Mar 2013 20:00:20 +0000 Message-ID: <5138F1D3.40502@alum.mit.edu> Date: Fri, 08 Mar 2013 04:00:19 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <5138E68B.5000003@alum.mit.edu> In-Reply-To: <5138E68B.5000003@alum.mit.edu> 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=1362686420; bh=jR5XFgy0NLTHSQOvEA+KwhF8jcRjkQKuBITjMzU19b4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Yfoi2WqVwKdfhnDXQ21eq2PcUWukM/r48gwjY1NkxnZ11rVGTTTl9wP5IeFm4GoHC qlOpMMANJ++Ep/EULWY3j6xpXVlxKLn0+ItcX77+ptqBPPfqb0gaboa3sTt9mC3cg5 k+LhV8YnAHj644XmUYU05Jklq3Oz/A+HKMsaheuGmbutSe6tO5zVcfUPJf6xqzqqeE Q5mhkP0O/k51UaW7dKzoJaEqvnZFa6+vHXrhfrHbJxU5sU+z6KBYCdCuXd85INCJRd M4mJ1MORE58haKHnqhPl6QI+OXv7/d9M12rEyA+CornnDure2Wyn2QcIn+2tjsOc3L EKuNGFINik+VQ== Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 20:00:24 -0000 Mary reminded me that I failed to indicate if I was speaking as an individual or a chair. I was definitely speaking as an individual. Sorry, Paul On 3/8/13 3:12 AM, Paul Kyzivat wrote: > I don't fully agree with Mary on this. > > First, I don't think that discussion in RTCWEB has much bearing on CLUE. > RTCWEB uses a non-sip signaling model. And it doesn't even call for use > of SDP in signaling. Rather it only uses SDP for communication between > the javascript and the browser it runs in. It doesn't require that the > SDP constructed in one broswer be identical to that seen in the browser > at the other end. SDP has long been a poor choice for the purpose we use > it, but we have legacy reasons to continue and efforts to move to SDPng > failed. It is extremely poor as an abstract conceptual representation > for an API. So IMO it makes sense to think hard about whether to use it > in RTCWEB. The argument there is not what to put in SDP and what to do > another way, it is about whether to use SDP or not. > > But CLUE is mostly SIP-based. We are going to be using SDP. For us the > question is how much to put in SDP and how much to put in the CLUE > protocol. I don't think the rtcweb arguments are helpful about that. > > IMO we should use SDP for the things it does, and perhaps extend it a > bit for things it *ought* to do, philosophically. SDP O/A is focused on > two ends negotiating based on what each is prepared to receive. > Sometimes it talks about what is to be sent, but it isn't so good about > that. In the end the result of the negotiation defines characteristics > of what *will* be sent. And that part is important to some middle boxes, > so we should try hard not to break that. > > Clue is focused on presenting a menu of what *could* be *sent* and then > selecting from that menu what should be sent, and how. It is pretty hard > to work out what SDP is required until all that is known. So I prefer > keeping the division that way - the SDP is only used to signal the > details to support what will be sent, based on what was agreed in the > clue signaling. > > In some cases this may lead to conflicts. For instance, SDP has the > a=content attribute. In our clue data model and signaling we will have a > much richer mechanism to describe similar characteristics. IMO we should > not feel a need to exclusively use SDP for this. I don't know that we > need to use it at all between clue-aware endpoints, though we ought to > do as much as we can when talking to legacy endpoints. > > So in practice I will probably agree with Mary most of the time about > what should be in SDP and what should not. > > I'll also observe that the less we depend on SDP the less trouble we > will have making CLUE work in RTCWEB. > > Thanks, > Paul > > On 3/8/13 2:08 AM, Mary Barnes wrote: >> I really think CLUE folks need to read this thread and understand the >> issues: >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html >> >> While we aren't defining an API, we are defining a application. I >> think it's important to carefully consider the tradeoffs in terms of >> how much is carried in SDP versus how much we can do with a CLUE >> specific protocol. >> >> >> I really, really think that the more we put in SDP, the less >> extensibility we will have for the CLUE application - I think we >> really, really need to carefully weigh the tradeoffs between tightly >> coupling the CLUE application to SDP versus minimizing the >> interactions and duplication of information. >> >> In one sense, this is a similar problem we faced with SIP >> conferencing. We defined some basic extensions that worked just fine. >> But, it would have been a bear to add all the additional functionality >> for complex scenarios to SIP. Instead, we defined XCON, which >> decouples the conferencing application from the session >> setup/signaling protocol. XCON is highly extensible and flexible and >> provides a rich set of application functionality. I believe we want >> to same with CLUE a >> >> >> >> Mary. >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Mar 7 12:03: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 B1DCB21F8CD1 for ; Thu, 7 Mar 2013 12:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, 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 ZISusIqpp9vg for ; Thu, 7 Mar 2013 12:03:42 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 89D7221F8CC9 for ; Thu, 7 Mar 2013 12:03:41 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-57-5138f29cd378 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E6.B7.32353.C92F8315; Thu, 7 Mar 2013 21:03:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 21:03:40 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] Just an FYI: Another analysis of SDP/RTCWEB Thread-Index: AQHOG23+0nQBXxuXBkmUC+edduTbtZiapqG8 Date: Thu, 7 Mar 2013 20:03:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B11627C@ESESSMB209.ericsson.se> References: 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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6cTxaBBv8maVvsP3WZ2eLz/v3M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfG4gviBec4K9ac+sTewPiPvYuRk0NCwETi dNcdZghbTOLCvfVsXYxcHEIChxglHl39zAThLGKUeLziBUsXIwcHm4CFRPc/bZAGEQEniQsv 37OA2MIC9hJ/dh1ngYg7SPS33mWFsI0k3u7+BBZnEVCRmL/kNyOIzSvgLfFjyTwwW0ggQGLO 5atgNqdAoMSFVxvB6hmBDvp+ag0TiM0sIC5x68l8JohDBSSW7DkPdbSoxMvH/1ghbEWJ9qcN jBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNe br6JERgJB7f8NtjBuOm+2CFGaQ4WJXHecNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY Dc6+ZF7fFpS9+GgbY7n27uX9MTPizroJbRQN992w8dWSnVPM9HIvzNapOr9ZtzbQV/rs9X0H GFyt4z71LbvaMG3JV8EiRdcluwJizG52eW37HLWfK2vm21VNZta+3jXMO5+f2hArk3D2UPyy Lq0HTTEPVF9/MCzK8asS7PFhKrQ+u3Na60QjJZbijERDLeai4kQApwKPxlICAAA= Subject: Re: [clue] Just an FYI: Another analysis of SDP/RTCWEB 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, 07 Mar 2013 20:03:42 -0000 Not sure I would call it a proper analysis, but it's fun reading... :) Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Thursday, 07 March 2013 9:57 PM To: CLUE Subject: [clue] Just an FYI: Another analysis of SDP/RTCWEB Here's another blog post that discusses the RTCWEB/SDP issues. I still believe some of this discussion is quite relevant - I *love* the photo: http://blog.webrtc.is/2013/02/26/sdp-in-webrtc-who-cares/ Just as it was discussed on the RTCWEB list, many of the SDP proponents are wanting to protect current products. That was the reason that SDPNG was abandoned. And, certainly, that can be deemed a fairly strong argument as it appears that it might at first appear to require more work not to reuse SDP as much as possible. However, I would contend that the interop challenge and changes required to SDP code will be more expensive in the long run than a solution that minimizes the dependency on SDP. Mary. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Mar 7 12:04: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 91DC921F89FD for ; Thu, 7 Mar 2013 12:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[AWL=0.217, 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 O9z1CnzXGpvN for ; Thu, 7 Mar 2013 12:04:36 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1A721F84DF for ; Thu, 7 Mar 2013 12:04:35 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id 8bR81l0050bG4ec53k4blj; Thu, 07 Mar 2013 20:04:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id 8k4a1l00e3ZTu2S3Pk4afp; Thu, 07 Mar 2013 20:04:34 +0000 Message-ID: <5138F2D0.50100@alum.mit.edu> Date: Fri, 08 Mar 2013 04:04:32 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> <061501ce1b32$91608660$b4219320$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B6A@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B116249@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B116249@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362686675; bh=z3xuxQfoM9WzQY4lzfBIElzTnjfc+2HoMVhQY6oRrFg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dvUVTTN6mWKdXqvfPo4KWWyI86howy7Hi+E7xwhlnViFa6/Zch8UDSKN8SYQCEUvH R8hxYg9da5LoBmaJKKV2Z5ToBIbCfavkDsySs6cKZQJKjgGhIT+9to4cSzleyXIZwt oeZzGCeW9pZz6gKJUDFD3spGPa1o7iO2FLhQcgDsBVdoiOh/woPdMd6RQsCW0LvlOW 7Ra51X68ucGBdBpZwWbTOsaq/4W8g/AArBnfqXT995xn+sy1wynXDfG7LRsXcEN3tf eE/kdt/jMxL2VapriHtp8CmpzO7T+U/SGDCgqz2Te5j1L7UMVZJvI0boxHaDs/iMX6 nnChpu/+Zegcg== Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 20:04:36 -0000 This is an example of why we need a discussion of switched captures in the framework, including the difference between site switching and segment switching, and the relationship between switched video captures and switched audio captures. Thanks, Paul On 3/8/13 3:48 AM, Christer Holmberg wrote: > > Hi, > >> I suggest we split the problem into two parts. >> >> 1) Subscribe to virtual captures, allow to server to forward based on information available on the server. The most normal scenario is to forward based on audio activity. >> >> 2) Setting policy for how the server should switch streams. Policies could be >> >> a. Active speaker (based on audio level) >> >> b. Round robin >> >> A client could then request two virtual streams (with capture id 1 and 2) with policy ‘active speaker’, that should mean that the two loudest speaker should be in either capture id 1 or 2, to avoid having the capture id changing. > > I don't think the the active speaker should change between virtual captures - I'd rather see one virtual capture with the "active speaker" role. > > Because, I might negotiate a HD quality stream for the capture associated with the active speaker, while I request thumbnail quality stream(s) for other participant(s). > > Regards, > > Christer > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 7. mars 2013 14:14 > To: Roni Even; clue@ietf.org > Subject: Re: [clue] Active speaker a role? > > Hi, > > The MCU will advertise, to me, that it can provide three media captures (as in your example). The MCU will then receive media from all other participants, do voice activation, and forward the media streams with the “current speaker”, “recenve-1” etc to me. > > How the other endpoints provide their media to the MCU, and what roles are used, is a separate story. > > Regards, > > Christer > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 7. maaliskuuta 2013 14:52 > To: Christer Holmberg; clue@ietf.org > Subject: RE: [clue] Active speaker a role? > > Hi, > I will try to understand. What you are saying that we will have, for example, three media captures, “current speaker”,”recent-1” and “recent-2”. This will be used for MCU that does voice activation video switching but sends more than one RTP stream to each receiver. > Roni > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 07 March, 2013 2:28 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] Active speaker a role? > > Hi, > >> I think that if we use CLUE to signal the active speaker, previous, Etc it will require many messages since the speakers change. > > I am not sure I understand. The idea is to have a MCU capture, and e.g. a single stream, and the MCU switches the content based on who is active. There is no need to re-negotiate anything. Or, what messages do you refer to? > >> The information who is speaking can be available from the CSRC or using the RTP header extension level attributes. RFC6465 provides the use case you discuss. > > I am not talking about WHO (as in whether it’s Alice, Bob or Carol) is talking, but that whoever is talking is provided from the MCU capture. > > Regards, > > Christer > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 07 March, 2013 1:32 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] Active speaker a role? > > Hi, > >> This is a point I made in the past that for switched capture it may be good to know what is the policy, can be active speaker, time switch (round robin) or other methods. > > Correct. So, the question is whether that policy can be seen as a “role”. > > There could also be “2nd recent speaker”, “3rd recent speaker” etc, but instead of defining a separate role for each of them, maybe we could have an attribute value, e.g. “recent-speaker=2”. > > This type of functionality is very important for devices with a limited number of streams, screens etc – it non-telepresence rooms. > >> As for your second question advertisement is what can be sent, you probably meant that the configure message should allow to select a specific switch policy, I think that the configure can only ask for something that was advertised > > Yes. > > Regards, > > Christer > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 07 March, 2013 10:19 AM > To: clue@ietf.org > Subject: [clue] Active speaker a role? > > Hi, > > A couple of questions related to the capture attribute draft. > > Q1. > > Assume you have a MCU, which collects streams from multiple endpoints, and provides the active speaker to a single screen entity. So, the content will change as the most active changes, but the capture provided by the MCU will be the same. > > So, the “role” of this capture would be “active speaker”. Or? > > > Q2. > > I assume that capture attribute can also be used during the advertisement phase. Ie a single entity can indicate that it is able to receive a stream, where it want the content to be the “active speaker” role. Or? > > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Thu Mar 7 12:08:00 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 29A8921F8C20 for ; Thu, 7 Mar 2013 12:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.074 X-Spam-Level: X-Spam-Status: No, score=0.074 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=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 RMH1sBWArWfc for ; Thu, 7 Mar 2013 12:07:59 -0800 (PST) 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 3D6B021F8C5C for ; Thu, 7 Mar 2013 12:07:59 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta09.westchester.pa.mail.comcast.net with comcast id 8iG11l0020vyq2s59k7yos; Thu, 07 Mar 2013 20:07:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id 8k7y1l0093ZTu2S3Rk7ys9; Thu, 07 Mar 2013 20:07:58 +0000 Message-ID: <5138F39E.5060204@alum.mit.edu> Date: Fri, 08 Mar 2013 04:07:58 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mary Barnes References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> In-Reply-To: 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=1362686878; bh=vSyqRiK4+jPGtTAHjhsXACFHtpIQSfG0aU/4kfrwdW4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ruHjx5JzDUdssOFOB3v239R6NbLtI17op3ZW71VQuB+P3p4EPxFwORKHNdLUv7UIB EJ4tCDrhsJDmpRUCHMAtZ6sDBZ2xNgkUJ7tcCIEJdzdD2r4QK3AWlDDK2scG8WaPZN 7b5DzelUHGNsq2WlEOX1CUfsz7g02SRXUgeNeOqRrHCNiPS3y3yA9JK4qcZbTBuAFP YZjHnlSwOrwutUidtFxfJIdSX81VYUlm59tKL1HsKyFkIlrDig+Bhm2X4ZPyXHYXcG FeAJ0LL4QqOfPY0ZuYVQ4EawziSbAXxjTqEC7r1fIdJ2yj/BUjTvUe+Euy+9RtcQ1G LfuoAc1FSe3Yw== Cc: CLUE Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 07 Mar 2013 20:08:00 -0000 (as individual) Perhaps we should talk in rtcweb about what we are doing in clue, and suggest that some of the understanding of what the multiple streams *mean* in rtcweb should be left as application-specific. Thanks, Paul On 3/8/13 3:48 AM, Mary Barnes wrote: > On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg > wrote: >> >> Hi, >> >> I agree with Paul. >> >> My personal starting point is still that the CLUE signalling should be used for the telepresence application related stuff, like spatial relationship etc. >> >> I also don't think that the RTCWEB outcome affect us, as far as our mechanism is concerned. However, if RTCWEB loses interest in pushing for SDP and/or RTP extensions that we also are interested in, WE may have to become more active in that work. > [MB] > I wasn't suggesting that their decision as to the > mechanism would directly impact CLUE. I'm suggesting that some of the > challenges they are having are due to the fact that they are trying to > use SDP for something that it really wasn't designed or envisioned to > be used for. I do believe that some of the issues with SDP that they > are encountering that is making folks rethink the RTCWEB decision are > not unlike those that CLUE may have to deal with. I strongly believe > that decoupling the CLUE application from SDP as much as possible is a > better path than trying to put so much into SDP (which is a *similar* > discussion as is happening in RTCWEB in terms of decoupling the API > from SDP). I understand that we are using SIP for session setup, so > of course, we will need to use SDP O/A and thus we can't totally > decouple. As we have been discussing for well over a year, the > challenge is how much of the CLUE application information should be > carried in SDP versus a CLUE specific protocol. > > > We should already be more active in the work and not > expect that we would just use what RTCWEB needs. CLUE requirements > should be considered equal to those of RTCWEB. I think we also need > to be very thoughtful as to how we make our decisions so we don't end > up a year from now with folks questioning the path we chose. > > >> >> Regards, >> >> Christer >> >> >> ________________________________________ >> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Thursday, 07 March 2013 9:12 PM >> To: Mary Barnes >> Cc: CLUE >> Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model >> >> I don't fully agree with Mary on this. >> >> First, I don't think that discussion in RTCWEB has much bearing on CLUE. >> RTCWEB uses a non-sip signaling model. And it doesn't even call for use >> of SDP in signaling. Rather it only uses SDP for communication between >> the javascript and the browser it runs in. It doesn't require that the >> SDP constructed in one broswer be identical to that seen in the browser >> at the other end. SDP has long been a poor choice for the purpose we use >> it, but we have legacy reasons to continue and efforts to move to SDPng >> failed. It is extremely poor as an abstract conceptual representation >> for an API. So IMO it makes sense to think hard about whether to use it >> in RTCWEB. The argument there is not what to put in SDP and what to do >> another way, it is about whether to use SDP or not. >> >> But CLUE is mostly SIP-based. We are going to be using SDP. For us the >> question is how much to put in SDP and how much to put in the CLUE >> protocol. I don't think the rtcweb arguments are helpful about that. >> >> IMO we should use SDP for the things it does, and perhaps extend it a >> bit for things it *ought* to do, philosophically. SDP O/A is focused on >> two ends negotiating based on what each is prepared to receive. >> Sometimes it talks about what is to be sent, but it isn't so good about >> that. In the end the result of the negotiation defines characteristics >> of what *will* be sent. And that part is important to some middle boxes, >> so we should try hard not to break that. >> >> Clue is focused on presenting a menu of what *could* be *sent* and then >> selecting from that menu what should be sent, and how. It is pretty hard >> to work out what SDP is required until all that is known. So I prefer >> keeping the division that way - the SDP is only used to signal the >> details to support what will be sent, based on what was agreed in the >> clue signaling. >> >> In some cases this may lead to conflicts. For instance, SDP has the >> a=content attribute. In our clue data model and signaling we will have a >> much richer mechanism to describe similar characteristics. IMO we should >> not feel a need to exclusively use SDP for this. I don't know that we >> need to use it at all between clue-aware endpoints, though we ought to >> do as much as we can when talking to legacy endpoints. >> >> So in practice I will probably agree with Mary most of the time about >> what should be in SDP and what should not. >> >> I'll also observe that the less we depend on SDP the less trouble we >> will have making CLUE work in RTCWEB. >> >> Thanks, >> Paul >> >> On 3/8/13 2:08 AM, Mary Barnes wrote: >>> I really think CLUE folks need to read this thread and understand the issues: >>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html >>> >>> While we aren't defining an API, we are defining a application. I >>> think it's important to carefully consider the tradeoffs in terms of >>> how much is carried in SDP versus how much we can do with a CLUE >>> specific protocol. >>> >>> >>> I really, really think that the more we put in SDP, the less >>> extensibility we will have for the CLUE application - I think we >>> really, really need to carefully weigh the tradeoffs between tightly >>> coupling the CLUE application to SDP versus minimizing the >>> interactions and duplication of information. >>> >>> In one sense, this is a similar problem we faced with SIP >>> conferencing. We defined some basic extensions that worked just fine. >>> But, it would have been a bear to add all the additional functionality >>> for complex scenarios to SIP. Instead, we defined XCON, which >>> decouples the conferencing application from the session >>> setup/signaling protocol. XCON is highly extensible and flexible and >>> provides a rich set of application functionality. I believe we want >>> to same with CLUE a >>> >>> >>> >>> Mary. >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Thu Mar 7 12:08: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 AFA7721F8CDB for ; Thu, 7 Mar 2013 12:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.016, 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 jdosrXH78Qb6 for ; Thu, 7 Mar 2013 12:08:32 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 40E5C21F8C78 for ; Thu, 7 Mar 2013 12:08:32 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-bc-5138f3bed236 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id F1.28.32353.EB3F8315; Thu, 7 Mar 2013 21:08:30 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 21:08:30 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkP//+iSA///ET0CAAHOcgP//7D3ggAAeSYD//+nn8AAOqeeAAASb+fwAAWepAAAAppq8 Date: Thu, 7 Mar 2013 20:08:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1162B2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <060601ce1b2d$4ef06a20$ecd13e60$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114A6D@ESESSMB209.ericsson.se> <061501ce1b32$91608660$b4219320$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B6A@ESESSMB209.ericsson.se>, <7594FB04B1934943A5C02806D1A2204B116249@ESESSMB209.ericsson.se>, <5138F2D0.50100@alum.mit.edu> In-Reply-To: <5138F2D0.50100@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.19] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje6+zxaBBh3frSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj6uFpzAXL9Squ/XvN1sD4U6WLkYNDQsBE YuIKwy5GTiBTTOLCvfVsXYxcHEIChxglOg9PZ4RwFjFK9HzvZgRpYBOwkOj+pw3SICLgKbHj 4xRmEFtYQEvi0O2PbBBxbYn+v5+YIew8ibVHLoLFWQRUJN4cO8oKMoZXwFviRI8YxPj9LBI7 mheB1XACzblx/jWYzQh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQtqJE+9MG Roh6A4n35+YzQ9jaEssWvgazeQUEJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWM7LmJmTnp 5eabGIGRcHDLb4MdjJvuix1ilOZgURLnDXe9ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB sUjx+CXBJVwqfD9MD683qpFfI/x3pvLeSHuOwkmd5f9M91fvWZ6rfMPEl9nv5qt7J1g7oo9q z5y2ye6Bps6qKxc9TuuJd/2OuLu48JtrifW0Cj13rxNsVYH3zL9ZPtmXpC1w7R3fcdVrr8s/ LPw2QflQ4NIH/488dI5bf2zB14NNOvF/Ll3enqHEUpyRaKjFXFScCAANoYIrUgIAAA== Subject: Re: [clue] Active speaker a role? 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, 07 Mar 2013 20:08:33 -0000 Hi, >This is an example of why we need a discussion of switched captures in >the framework, including the difference between site switching and >segment switching, and the relationship between switched video captures >and switched audio captures. The relationship between audio and video captures is a general issue, not o= nly related to switching. Regards, Christer On 3/8/13 3:48 AM, Christer Holmberg wrote: > > Hi, > >> I suggest we split the problem into two parts. >> >> 1) Subscribe to virtual captures, allow to server to forward based = on information available on the server. The most normal scenario is to forw= ard based on audio activity. >> >> 2) Setting policy for how the server should switch streams. Policie= s could be >> >> a. Active speaker (based on audio level) >> >> b. Round robin >> >> A client could then request two virtual streams (with capture id 1 and 2= ) with policy =91active speaker=92, that should mean that the two loudest s= peaker should be in either capture id 1 or 2, to avoid having the capture i= d changing. > > I don't think the the active speaker should change between virtual captur= es - I'd rather see one virtual capture with the "active speaker" role. > > Because, I might negotiate a HD quality stream for the capture associated= with the active speaker, while I request thumbnail quality stream(s) for o= ther participant(s). > > Regards, > > Christer > > > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of C= hrister Holmberg > Sent: 7. mars 2013 14:14 > To: Roni Even; clue@ietf.org > Subject: Re: [clue] Active speaker a role? > > Hi, > > The MCU will advertise, to me, that it can provide three media captures (= as in your example). The MCU will then receive media from all other partici= pants, do voice activation, and forward the media streams with the =93curre= nt speaker=94, =93recenve-1=94 etc to me. > > How the other endpoints provide their media to the MCU, and what roles ar= e used, is a separate story. > > Regards, > > Christer > > > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: 7. maaliskuuta 2013 14:52 > To: Christer Holmberg; clue@ietf.org > Subject: RE: [clue] Active speaker a role? > > Hi, > I will try to understand. What you are saying that we will have, for exam= ple, three media captures, =93current speaker=94,=94recent-1=94 and =93rece= nt-2=94. This will be used for MCU that does voice activation video switchi= ng but sends more than one RTP stream to each receiver. > Roni > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 07 March, 2013 2:28 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] Active speaker a role? > > Hi, > >> I think that if we use CLUE to signal the active speaker, previous, Etc = it will require many messages since the speakers change. > > I am not sure I understand. The idea is to have a MCU capture, and e.g. a= single stream, and the MCU switches the content based on who is active. Th= ere is no need to re-negotiate anything. Or, what messages do you refer to? > >> The information who is speaking can be available from the CSRC or using = the RTP header extension level attributes. RFC6465 provides the use case yo= u discuss. > > I am not talking about WHO (as in whether it=92s Alice, Bob or Carol) is = talking, but that whoever is talking is provided from the MCU capture. > > Regards, > > Christer > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: 07 March, 2013 1:32 PM > To: Roni Even; clue@ietf.org > Subject: RE: [clue] Active speaker a role? > > Hi, > >> This is a point I made in the past that for switched capture it may be g= ood to know what is the policy, can be active speaker, time switch (round r= obin) or other methods. > > Correct. So, the question is whether that policy can be seen as a =93role= =94. > > There could also be =932nd recent speaker=94, =933rd recent speaker=94 et= c, but instead of defining a separate role for each of them, maybe we could= have an attribute value, e.g. =93recent-speaker=3D2=94. > > This type of functionality is very important for devices with a limited n= umber of streams, screens etc =96 it non-telepresence rooms. > >> As for your second question advertisement is what can be sent, you proba= bly meant that the configure message should allow to select a specific swit= ch policy, I think that the configure can only ask for something that was a= dvertised > > Yes. > > Regards, > > Christer > > > > From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On Behalf Of Christer Holmberg > Sent: 07 March, 2013 10:19 AM > To: clue@ietf.org > Subject: [clue] Active speaker a role? > > Hi, > > A couple of questions related to the capture attribute draft. > > Q1. > > Assume you have a MCU, which collects streams from multiple endpoints, an= d provides the active speaker to a single screen entity. So, the content wi= ll change as the most active changes, but the capture provided by the MCU w= ill be the same. > > So, the =93role=94 of this capture would be =93active speaker=94. Or? > > > Q2. > > I assume that capture attribute can also be used during the advertisement= phase. Ie a single entity can indicate that it is able to receive a stream= , where it want the content to be the =93active speaker=94 role. Or? > > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Mar 7 18:57: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 C399121F8675 for ; Thu, 7 Mar 2013 18:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Qv366tCmtgou for ; Thu, 7 Mar 2013 18:57:18 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id BB7BD21F862B for ; Thu, 7 Mar 2013 18:57:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAANSOVF20fUb/2dsb2JhbAANLQrEUIF1gyABAQEEAQEBNRsbChELGAkWDwkDAgECARUwEwYCAQGIG6hOkwgEjVGBQhaDKgOTB5dS Received: from ppp118-209-245-27.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.245.27]) by ipmail04.adl6.internode.on.net with ESMTP; 08 Mar 2013 13:27:16 +1030 Message-ID: <51395383.1080207@nteczone.com> Date: Fri, 08 Mar 2013 13:57:07 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512A9240.3040800@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539E39@CRPMBOXPRD01.polycom.com> <5136224C.4020000@alum.mit.edu> <513807AE.1050303@nteczone.com> <5138A94D.9020703@alum.mit.edu> In-Reply-To: <5138A94D.9020703@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] New framework I-D posted 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, 08 Mar 2013 02:57:18 -0000 Hello Paul, I'm not asking to restrict the usage of SDP. What i'd like to avoid is in the framework to mandate the use of SDP (+specific RFCs) for an endpoint to use the CLUE signalling protocol. For the CLUE protocol signalling there's currently no reason to say that SDP should be supported. SDP offer/answer comes into play to setup up the SCTP connection and to establish the actual media streams. So I see CLUE as just CLUE, not SIP CLUE, sort of like BFCP which we don't call SIP BFCP. Regards, Christian On 8/03/2013 1:50 AM, Paul Kyzivat wrote: > On 3/7/13 11:21 AM, Christian Groves wrote: > >>>> [Duckworth, Mark] I agree, Paul. If this is what the group wants, >>>> the framework document should clearly say CLUE devices follow all SDP >>>> O/A rules. Should we also refer to some specific RFCs? >>> >>> Since we are talking about SDP, we can at least reference 4566 and >>> draft-ietf-mmusic-rfc4566bis. I don't think we need to mention any SDP >>> extensions here unless we have reason to talk about them explicitly. >> >> [CNG] I'd be a little hesitant to mandate that a devices supporting CLUE >> must support SDP O/A. That may not make much sense for non-SIP devices. >> Yes I know this working group is only working on SIP CLUE but the >> charter says we should identify interoperability obstacles in existing >> open standards > > We are working on SIP CLUE. When doing that it is necessary to conform > to SDP O/A. Normally I would think that there is no need to emphasize > that because it is implicit in supporting SIP. > > But in this case there really may be a reason to talk about it: we do > have another channel in which to negotiate things. Along the way there > have been some suggestions that we might negotiate some media streams > in the clue channel that weren't mentioned at all in SDP. I want to > make it clear that we are *not* proposing to do that. > > If/when an H.323 version of clue is derived from this it can make the > appropriate corresponding statements for H.323. > > Or do you think we need to be more restrictive in our use of SDP in > order to facilitate interop with H.323? > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Mar 7 19:04:06 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 90FB021F850E for ; Thu, 7 Mar 2013 19:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 62xBe-wZ3IgM for ; Thu, 7 Mar 2013 19:04:05 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 4361221F8507 for ; Thu, 7 Mar 2013 19:04:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIxUOVF20fUb/2dsb2JhbAANN8RQgXWDIAEBAQQBAQE1GxsKEQsYCRYPCQMCAQIBFTATBgIBAYgbqFmTCQSPExaDKgOqWQ Received: from ppp118-209-245-27.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.245.27]) by ipmail04.adl6.internode.on.net with ESMTP; 08 Mar 2013 13:34:02 +1030 Message-ID: <5139551B.8030707@nteczone.com> Date: Fri, 08 Mar 2013 14:03:55 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512EF700.2080207@nteczone.com> <9C23AB934B394845A7B228239B6EAF41539E72@CRPMBOXPRD01.polycom.com> <51381304.7010706@nteczone.com> <5138AB18.7020205@alum.mit.edu> In-Reply-To: <5138AB18.7020205@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] New framework I-D posted 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, 08 Mar 2013 03:04:06 -0000 Hello Paul, I don't see much text in the framework on the actual method. I was more thinking a more high level description i.e. "Advertisement and Configures are acknowledged by the remote endpoint. A consumer always sends a Configure in response to an initial Advertisement. For subsequent Advertisements it is optional to send a Configure." If we have the framework and protocol document they should be aligned. If we leave the text to say something like "the Consumer must send a new Configure in response to receiving an Advertisement." and the protocol says something different them for sure when it comes to interop testing somebody is going to say "but the framework said..." where their protocol doesn't work... Regards, Christian On 8/03/2013 1:58 AM, Paul Kyzivat wrote: > On 3/7/13 12:09 PM, Christian Groves wrote: > >>>> Section 9. pg. 32 para.4: Not sure that each Advertise is >>>> acknowledged by a >>>> Configure. Acknowledge of the receipt of a message and configuration >>>> could >>>> be separate. >>> [Duckworth, Mark] The intent is to say something like the Consumer >>> must send a new Configure in response to receiving an Advertisement. >>> Does that make more sense? I agree this could be separate from >>> acknowledging receipt of the Advertisement. >> [CNG] For the initial Advertisement the Consumer must send a Configure. >> For subsequent Advertisements the consumer only has to send a Configure >> if something in the new Advertisement has changed the consumer state and >> it needs to send a Configure. The consumer should always ack/nack the >> reception of an Advertisement. > > IMO this starts to get into protocol details. So I would like to avoid > talking about this in the FW if possible. If it seems necessary to > talk about it, then we will need to be careful to synchronize with the > signaling. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Mar 7 19:16:41 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 219D921F867A for ; Thu, 7 Mar 2013 19:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 6+bsF4sU1vTz for ; Thu, 7 Mar 2013 19:16:40 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id C202421F865D for ; Thu, 7 Mar 2013 19:16:39 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAL5WOVF20fUb/2dsb2JhbAANN8RQgXWDIAEBBQEBNhsbGwsYCSUPAhYwEwgBAbB2kwkEjxODQAOqWQ Received: from ppp118-209-245-27.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.245.27]) by ipmail04.adl6.internode.on.net with ESMTP; 08 Mar 2013 13:44:54 +1030 Message-ID: <513957A1.20102@nteczone.com> Date: Fri, 08 Mar 2013 14:14:41 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se>, <5138B68E.6010203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B114EC2@ESESSMB209.ericsson.se> <5138CAE0.4010103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B115FD1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B115FD1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 03:16:41 -0000 Hello Christer, From an application level I think the capture attributes should provide a means to select the audio captures. There may or may not be a one to one mapping. For example a video may have multiple audio feeds (i.e. different languages). The consumer can chose one or more of these audio feeds. In the role case there's no reason why both the audio and video captures can't be labelled with the role. Linking the video and audio captures with an ID could provide more explicit information. The ids would have to be consistent with the capture attributes. I guess we could say if these additional Audio CSEs aren't included in the Video CSE then it means to use the default behaviour we already defined? Regards, Christian On 8/03/2013 4:30 AM, Christer Holmberg wrote: > Hi, > >>>>> Do we assume there is a one-to-one mapping between video and audio captures? >>>>> >>>>> For example, assume one video capture has the role "manager". >>>>> >>>>> That doesn't mean that there will be an audio capture with the same role, because the audio capture may cover a bigger area, including many persons. >>>>> >>>>> So, if I show the manager on my screen, how do I know which audio capture to choose? >>>> I too have wondered about this, and have no great answer. >>>> >>>> The simple answer is use spatial coordinates. But I'm not at all >>>> convinced that is a complete answer. >>> Also, you can have multiple video CSEs, and multiple audio CSEs, and the choise of audio CSE may depend on the choise of video CSE. So, is there a reason why we can't put different media types in the same CSE, if they are associated? I think it would help alot. >>> >>> But, that still doesn't solve the problem about, though, if you e.g. from a CSE only choose a specific set of video captures, and also want the corresponding audio captures. Maybe spatial coordinates helps there. >> I agree that this seems to be an issue that deserves more study. >> Is somebody willing to think hard about it and come back with an analysis? >> >> It certainly would be possible to redefine CSEs so that they contain captures of different media types. The good of it is that it mostly solves the problem you present. > It helps picking CSEs, but it still does not map individual captures :) > >> The bad of it is that it will increase the number of CSEs. (If under the current scheme there are N audio CSEs and M video CSEs (total N+M) then under this new approach there would be N*M CSEs, and each would be >> bigger.) But for common cases this may still be manageable. > Another way would be to keep them separate, but assign an identifier for each CSE, and then e.g. in each video CSE list the identifiers of all audio CSEs that can be used with that particular video CSE. > > Regards, > > Christer > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Thu Mar 7 19:35:48 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 7B47021F869E for ; Thu, 7 Mar 2013 19:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZJusugCVGrx for ; Thu, 7 Mar 2013 19:35:47 -0800 (PST) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id E280B21F865D for ; Thu, 7 Mar 2013 19:35:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIxbOVF20fUb/2dsb2JhbAANN8RQgXWDIAEBBQEBGxsbFAcEBhELEQQBAQEJFg8JAwIBAgEVKAgTCAEBBbB0kwyNW4EmEoNAA5JNmAyBXg Received: from ppp118-209-245-27.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.245.27]) by ipmail04.adl6.internode.on.net with ESMTP; 08 Mar 2013 14:03:42 +1030 Message-ID: <51395C0F.2010201@nteczone.com> Date: Fri, 08 Mar 2013 14:33:35 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> <5138F39E.5060204@alum.mit.edu> In-Reply-To: <5138F39E.5060204@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 08 Mar 2013 03:35:48 -0000 Hello, I think part of the problem may be that when people talk about "CLUE" they actually mean different things. For me there's two aspects: 1) CLUE as a signalling protocol, and 2) how to use CLUE in a SIP network. For 1) I can't see any need to incorporate SDP into the CLUE signalling. For 2) SDP will be required in SIP networks to establish the CLUE data channel. SDP will also be required to establish the media. It would be good for people to clarify what they mean when they are talking about SDP. I personally think the RTCWEB work is a distraction and likewise the RTPMUX work for the CLUE signalling protocol. RTPMUX is important for the establishment of media. Regards, Christian On 8/03/2013 7:07 AM, Paul Kyzivat wrote: > (as individual) > > Perhaps we should talk in rtcweb about what we are doing in clue, and > suggest that some of the understanding of what the multiple streams > *mean* in rtcweb should be left as application-specific. > > Thanks, > Paul > > On 3/8/13 3:48 AM, Mary Barnes wrote: >> On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg >> wrote: >>> >>> Hi, >>> >>> I agree with Paul. >>> >>> My personal starting point is still that the CLUE signalling should >>> be used for the telepresence application related stuff, like spatial >>> relationship etc. >>> >>> I also don't think that the RTCWEB outcome affect us, as far as our >>> mechanism is concerned. However, if RTCWEB loses interest in pushing >>> for SDP and/or RTP extensions that we also are interested in, WE may >>> have to become more active in that work. >> [MB] >> I wasn't suggesting that their decision as to the >> mechanism would directly impact CLUE. I'm suggesting that some of the >> challenges they are having are due to the fact that they are trying to >> use SDP for something that it really wasn't designed or envisioned to >> be used for. I do believe that some of the issues with SDP that they >> are encountering that is making folks rethink the RTCWEB decision are >> not unlike those that CLUE may have to deal with. I strongly believe >> that decoupling the CLUE application from SDP as much as possible is a >> better path than trying to put so much into SDP (which is a *similar* >> discussion as is happening in RTCWEB in terms of decoupling the API >> from SDP). I understand that we are using SIP for session setup, so >> of course, we will need to use SDP O/A and thus we can't totally >> decouple. As we have been discussing for well over a year, the >> challenge is how much of the CLUE application information should be >> carried in SDP versus a CLUE specific protocol. >> >> >> We should already be more active in the work and not >> expect that we would just use what RTCWEB needs. CLUE requirements >> should be considered equal to those of RTCWEB. I think we also need >> to be very thoughtful as to how we make our decisions so we don't end >> up a year from now with folks questioning the path we chose. >> >> >>> >>> Regards, >>> >>> Christer >>> >>> >>> ________________________________________ >>> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of >>> Paul Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: Thursday, 07 March 2013 9:12 PM >>> To: Mary Barnes >>> Cc: CLUE >>> Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model >>> >>> I don't fully agree with Mary on this. >>> >>> First, I don't think that discussion in RTCWEB has much bearing on >>> CLUE. >>> RTCWEB uses a non-sip signaling model. And it doesn't even call for use >>> of SDP in signaling. Rather it only uses SDP for communication between >>> the javascript and the browser it runs in. It doesn't require that the >>> SDP constructed in one broswer be identical to that seen in the browser >>> at the other end. SDP has long been a poor choice for the purpose we >>> use >>> it, but we have legacy reasons to continue and efforts to move to SDPng >>> failed. It is extremely poor as an abstract conceptual representation >>> for an API. So IMO it makes sense to think hard about whether to use it >>> in RTCWEB. The argument there is not what to put in SDP and what to do >>> another way, it is about whether to use SDP or not. >>> >>> But CLUE is mostly SIP-based. We are going to be using SDP. For us the >>> question is how much to put in SDP and how much to put in the CLUE >>> protocol. I don't think the rtcweb arguments are helpful about that. >>> >>> IMO we should use SDP for the things it does, and perhaps extend it a >>> bit for things it *ought* to do, philosophically. SDP O/A is focused on >>> two ends negotiating based on what each is prepared to receive. >>> Sometimes it talks about what is to be sent, but it isn't so good about >>> that. In the end the result of the negotiation defines characteristics >>> of what *will* be sent. And that part is important to some middle >>> boxes, >>> so we should try hard not to break that. >>> >>> Clue is focused on presenting a menu of what *could* be *sent* and then >>> selecting from that menu what should be sent, and how. It is pretty >>> hard >>> to work out what SDP is required until all that is known. So I prefer >>> keeping the division that way - the SDP is only used to signal the >>> details to support what will be sent, based on what was agreed in the >>> clue signaling. >>> >>> In some cases this may lead to conflicts. For instance, SDP has the >>> a=content attribute. In our clue data model and signaling we will >>> have a >>> much richer mechanism to describe similar characteristics. IMO we >>> should >>> not feel a need to exclusively use SDP for this. I don't know that we >>> need to use it at all between clue-aware endpoints, though we ought to >>> do as much as we can when talking to legacy endpoints. >>> >>> So in practice I will probably agree with Mary most of the time about >>> what should be in SDP and what should not. >>> >>> I'll also observe that the less we depend on SDP the less trouble we >>> will have making CLUE work in RTCWEB. >>> >>> Thanks, >>> Paul >>> >>> On 3/8/13 2:08 AM, Mary Barnes wrote: >>>> I really think CLUE folks need to read this thread and understand >>>> the issues: >>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html >>>> >>>> While we aren't defining an API, we are defining a application. I >>>> think it's important to carefully consider the tradeoffs in terms of >>>> how much is carried in SDP versus how much we can do with a CLUE >>>> specific protocol. >>>> >>>> >>>> I really, really think that the more we put in SDP, the less >>>> extensibility we will have for the CLUE application - I think we >>>> really, really need to carefully weigh the tradeoffs between tightly >>>> coupling the CLUE application to SDP versus minimizing the >>>> interactions and duplication of information. >>>> >>>> In one sense, this is a similar problem we faced with SIP >>>> conferencing. We defined some basic extensions that worked just fine. >>>> But, it would have been a bear to add all the additional functionality >>>> for complex scenarios to SIP. Instead, we defined XCON, which >>>> decouples the conferencing application from the session >>>> setup/signaling protocol. XCON is highly extensible and flexible and >>>> provides a rich set of application functionality. I believe we want >>>> to same with CLUE a >>>> >>>> >>>> >>>> Mary. >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Fri Mar 8 03:43: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 D5CE321F863B for ; Fri, 8 Mar 2013 03:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.015, 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 3ILuPihudwS4 for ; Fri, 8 Mar 2013 03:43:52 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0162C21F8629 for ; Fri, 8 Mar 2013 03:43:51 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-64-5139cef6637d Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E2.9D.32353.6FEC9315; Fri, 8 Mar 2013 12:43:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 12:43:50 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] comments to framework 09 - simultaneous sets Thread-Index: AQHOFRraUKiwrhHulkuizxJIqSgIUpiYs+6AgAALTQCAAD7qAIAApfyAgACEJACAABFUkIAAIY8AgAAhbAX///bNAIAAE9rggACT8YCAAJ22QA== Date: Fri, 8 Mar 2013 11:43:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B116AA1@ESESSMB209.ericsson.se> References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se>, <5138B68E.6010203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B114EC2@ESESSMB209.ericsson.se> <5138CAE0.4010103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B115FD1@ESESSMB209.ericsson.se> <513957A1.20102@nteczone.com> In-Reply-To: <513957A1.20102@nteczone.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvje73c5aBBnNWclp8ed/IYrH/1GVm ByaPJUt+MnmsOD+TJYApissmJTUnsyy1SN8ugSvj2ZYNTAVbZSpeH/3C3sB4RayLkZNDQsBE 4tDmiSwQtpjEhXvr2boYuTiEBA4xSqybegLKWcQocbO9j7GLkYODTcBCovufNkiDiEC4RMe2 K4wgtrCAg0TLrymsEHFHiVWr5rFA2HUS5zdcZAKxWQRUJBb2Pgar4RXwllg+ezUrxPxTLBIT Ww6zgyQ4BbQkpu54xwxiMwJd9P3UGrBmZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/rBC2osTV 6cuh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMn vdx8EyMwGg5u+W2wg3HTfbFDjNIcLErivOGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MHLyLfHXu+n43sDr19H/19ftc+/7aaayIe38pSxeX0de7RCXJfWBi6bUewr9CludZbuTi23V rtpJq9629TJPWZAY9uLL0f6go/8P+ZRFb5X0u87UGDWtL01nNcemGca5T1O2ytlmxGv7WDw1 XKYfxfJx2aPXT5IPKMbz3dtrH73M7bZoe4btDCWW4oxEQy3mouJEAPCcdihUAgAA Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 11:43:53 -0000 Hi, >From an application level I think the capture attributes should provide a = means to select the audio captures. There may or may not be a one to one ma= pping. For example a video may have multiple audio feeds (i.e.=20 >different languages). The consumer can chose one or more of these audio fe= eds. > >In the role case there's no reason why both the audio and video captures c= an't be labelled with the role. > >Linking the video and audio captures with an ID could provide more explici= t information. The ids would have to be=20 >consistent with the capture attributes. I guess we could say if these addi= tional Audio CSEs aren't included in the=20 >Video CSE then it means to use the default behaviour we already defined? Assume there are two video captures: "Christian" and "Paul". Then, there is a single audio capture, which provides audio for both "Chris= tian" and "Paul".=20 Now, the role of that audio capture can not be "Christian" alone, and it ca= n not be "Paul" alone. Of course, it CAN be "Christian" AND "Paul", if we allow a capture to have = multiple roles. Maybe that is already allowed, so my apologies if I've miss= ed it :) Regards, Christer On 8/03/2013 4:30 AM, Christer Holmberg wrote: > Hi, > >>>>> Do we assume there is a one-to-one mapping between video and audio ca= ptures? >>>>> >>>>> For example, assume one video capture has the role "manager". >>>>> >>>>> That doesn't mean that there will be an audio capture with the same r= ole, because the audio capture may cover a bigger area, including many pers= ons. >>>>> >>>>> So, if I show the manager on my screen, how do I know which audio cap= ture to choose? >>>> I too have wondered about this, and have no great answer. >>>> >>>> The simple answer is use spatial coordinates. But I'm not at all=20 >>>> convinced that is a complete answer. >>> Also, you can have multiple video CSEs, and multiple audio CSEs, and th= e choise of audio CSE may depend on the choise of video CSE. So, is there a= reason why we can't put different media types in the same CSE, if they are= associated? I think it would help alot. >>> >>> But, that still doesn't solve the problem about, though, if you e.g. fr= om a CSE only choose a specific set of video captures, and also want the co= rresponding audio captures. Maybe spatial coordinates helps there. >> I agree that this seems to be an issue that deserves more study. >> Is somebody willing to think hard about it and come back with an analysi= s? >> >> It certainly would be possible to redefine CSEs so that they contain cap= tures of different media types. The good of it is that it mostly solves the= problem you present. > It helps picking CSEs, but it still does not map individual captures=20 > :) > >> The bad of it is that it will increase the number of CSEs. (If under=20 >> the current scheme there are N audio CSEs and M video CSEs (total=20 >> N+M) then under this new approach there would be N*M CSEs, and each=20 >> would be >> bigger.) But for common cases this may still be manageable. > Another way would be to keep them separate, but assign an identifier for = each CSE, and then e.g. in each video CSE list the identifiers of all audio= CSEs that can be used with that particular video CSE. > > Regards, > > Christer > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Fri Mar 8 03:48: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 F1BA221F874C for ; Fri, 8 Mar 2013 03:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 zUlt9sDKcqZ9 for ; Fri, 8 Mar 2013 03:48:27 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C768121F8738 for ; Fri, 8 Mar 2013 03:48:26 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-04-5139d009529e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id DD.F5.10459.900D9315; Fri, 8 Mar 2013 12:48:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 12:48:25 +0100 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] New framework I-D posted Thread-Index: AQHOEIsDKRDSoTZdfE+rJkHvzWf+N5iJiIoAgAyfhgCAASkhAIACQp8AgADAq4CAAMrogIAApBqA Date: Fri, 8 Mar 2013 11:48:25 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B116AB8@ESESSMB209.ericsson.se> References: <512A9240.3040800@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF41539E39@CRPMBOXPRD01.polycom.com> <5136224C.4020000@alum.mit.edu> <513807AE.1050303@nteczone.com> <5138A94D.9020703@alum.mit.edu> <51395383.1080207@nteczone.com> In-Reply-To: <51395383.1080207@nteczone.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjS7nBctAgysPLS2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJUx88dy5oKTUhWXj05nb2BcINrFyMkhIWAi sWJrIwuELSZx4d56NhBbSOAQo8S/z+kQ9iJGiS13zLsYOTjYBCwkuv9pg4RFBMIlOrZdYQSx hQV0JGY3fGOBiOtKTN77kxmkXEQgSmLlknqQMIuAisT/T03MIDavgLfEjGm/gcq5gKZPYZJ4 fK0PrJcTaM6z3mdgRYxA53w/tYYJxGYWEJe49WQ+E8SZAhJL9pxnhrBFJV4+/scKYStKXJ2+ HKpeR2LB7k9sELa2xLKFr6EWC0qcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGNlzEzNz0ssN NzEC4+Dglt+6OxhPnRM5xCjNwaIkzhvmeiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OB 6uoGj9PLLxS89DA1zpB9sJF32tN5a0qYjdR+P2pys9tfOy3yqb3DnWP/J6rE8U6JTWV9wjjn I2vOvcf9P/02cnOeYPN69shHRHvbwwlyk6d6+px7e+3ktIQQH+Z/B3Nyko3/7ok9+HHxtjn1 B3c+711qcTp9Y8HnwnSX30WvZ0denvHEfdoCJZbijERDLeai4kQAyK+CsVECAAA= Subject: Re: [clue] New framework I-D posted 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, 08 Mar 2013 11:48:28 -0000 Hi, The simple way is to say that SDP is used to create the media streams, and = the CLUE is used to exchange the telepresence information. The only "connec= tion" is that we need to map the m- lines (or, perhaps individual SSRCs) in= the SDP with the corresponding captures in the CLUE signaling. The problem is that there is information that one could claim belongs in bo= th SDP and CLUE. If we decide to put such information in SDP, then CLUE doe= s become dependent on SDP (or, SOME other protocol) for transporting that i= nformation. But, that is not the same as "putting SDP in CLUE". Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= istian Groves Sent: 8. maaliskuuta 2013 4:57 To: clue@ietf.org Subject: Re: [clue] New framework I-D posted Hello Paul, I'm not asking to restrict the usage of SDP. What i'd like to avoid is in t= he framework to mandate the use of SDP (+specific RFCs) for an endpoint to = use the CLUE signalling protocol. For the CLUE protocol signalling there's = currently no reason to say that SDP should be supported. SDP offer/answer c= omes into play to setup up the SCTP connection and to establish the actual = media streams. So I see CLUE as just CLUE, not SIP CLUE, sort of like BFCP = which we don't call SIP BFCP. Regards, Christian On 8/03/2013 1:50 AM, Paul Kyzivat wrote: > On 3/7/13 11:21 AM, Christian Groves wrote: > >>>> [Duckworth, Mark] I agree, Paul. If this is what the group wants,=20 >>>> the framework document should clearly say CLUE devices follow all=20 >>>> SDP O/A rules. Should we also refer to some specific RFCs? >>> >>> Since we are talking about SDP, we can at least reference 4566 and=20 >>> draft-ietf-mmusic-rfc4566bis. I don't think we need to mention any=20 >>> SDP extensions here unless we have reason to talk about them explicitly= . >> >> [CNG] I'd be a little hesitant to mandate that a devices supporting=20 >> CLUE must support SDP O/A. That may not make much sense for non-SIP devi= ces. >> Yes I know this working group is only working on SIP CLUE but the=20 >> charter says we should identify interoperability obstacles in=20 >> existing open standards > > We are working on SIP CLUE. When doing that it is necessary to conform=20 > to SDP O/A. Normally I would think that there is no need to emphasize=20 > that because it is implicit in supporting SIP. > > But in this case there really may be a reason to talk about it: we do=20 > have another channel in which to negotiate things. Along the way there=20 > have been some suggestions that we might negotiate some media streams=20 > in the clue channel that weren't mentioned at all in SDP. I want to=20 > make it clear that we are *not* proposing to do that. > > If/when an H.323 version of clue is derived from this it can make the=20 > appropriate corresponding statements for H.323. > > Or do you think we need to be more restrictive in our use of SDP in=20 > order to facilitate interop with H.323? > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Mar 8 07:10:54 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 BCC2321F8700 for ; Fri, 8 Mar 2013 07:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=0.190, 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 K727B2tOQgVJ for ; Fri, 8 Mar 2013 07:10:54 -0800 (PST) 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 EB66721F86EF for ; Fri, 8 Mar 2013 07:10:53 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta09.westchester.pa.mail.comcast.net with comcast id 90e71l0011ei1Bg593At0S; Fri, 08 Mar 2013 15:10:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 93As1l00o3ZTu2S3k3AtgU; Fri, 08 Mar 2013 15:10:53 +0000 Message-ID: <5139FF7C.9010600@alum.mit.edu> Date: Fri, 08 Mar 2013 23:10:52 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se>, <5138B68E.6010203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B114EC2@ESESSMB209.ericsson.se> <5138CAE0.4010103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B115FD1@ESESSMB209.ericsson.se> <513957A1.20102@nteczone.com> In-Reply-To: <513957A1.20102@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=1362755453; bh=//S1rlN0yQ3Jpet9rejl3qRAa7lxbo4UbGAgamW2O14=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ca/cpbXiuPRUm2ftsPuNGtJdqYCWeaaBwJNb1kUpS1NJa5amujvIz4u1WmlAJP2lC K1sOrxrfA3HhJdag1tgHQGU/1AGxWln6uIoQw+itV382GLAoKAKi/pRW0BIyr8VNPG ycKLyQiIGH1N/WO+owC5cukbSAz87glRzV/5dPZRekgjLLvPQiZmNaDODtiF3zJNto Xvd4ei1nJALibL/KXM0JVEezaamIX8GcJgmgAErmUXVIUwbHR0DdrPWVzCuVll9I93 xAo6QmK74kwSBKHkGJDh3bY9gYw0RMPH7PaHsJL6EASmUdjci+BXkT3f0bOnbm/Gw6 tR/rhH9aLkNWQ== Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 15:10:54 -0000 ISTM that there is an issue around correlating audio and video captures. Do others think so? Thanks, Paul On 3/8/13 11:14 AM, Christian Groves wrote: > Hello Christer, > > From an application level I think the capture attributes should provide > a means to select the audio captures. There may or may not be a one to > one mapping. For example a video may have multiple audio feeds (i.e. > different languages). The consumer can chose one or more of these audio > feeds. > > In the role case there's no reason why both the audio and video captures > can't be labelled with the role. > > Linking the video and audio captures with an ID could provide more > explicit information. The ids would have to be consistent with the > capture attributes. I guess we could say if these additional Audio CSEs > aren't included in the Video CSE then it means to use the default > behaviour we already defined? > > Regards, Christian > > > On 8/03/2013 4:30 AM, Christer Holmberg wrote: >> Hi, >> >>>>>> Do we assume there is a one-to-one mapping between video and audio >>>>>> captures? >>>>>> >>>>>> For example, assume one video capture has the role "manager". >>>>>> >>>>>> That doesn't mean that there will be an audio capture with the >>>>>> same role, because the audio capture may cover a bigger area, >>>>>> including many persons. >>>>>> >>>>>> So, if I show the manager on my screen, how do I know which audio >>>>>> capture to choose? >>>>> I too have wondered about this, and have no great answer. >>>>> >>>>> The simple answer is use spatial coordinates. But I'm not at all >>>>> convinced that is a complete answer. >>>> Also, you can have multiple video CSEs, and multiple audio CSEs, and >>>> the choise of audio CSE may depend on the choise of video CSE. So, >>>> is there a reason why we can't put different media types in the same >>>> CSE, if they are associated? I think it would help alot. >>>> >>>> But, that still doesn't solve the problem about, though, if you e.g. >>>> from a CSE only choose a specific set of video captures, and also >>>> want the corresponding audio captures. Maybe spatial coordinates >>>> helps there. >>> I agree that this seems to be an issue that deserves more study. >>> Is somebody willing to think hard about it and come back with an >>> analysis? >>> >>> It certainly would be possible to redefine CSEs so that they contain >>> captures of different media types. The good of it is that it mostly >>> solves the problem you present. >> It helps picking CSEs, but it still does not map individual captures :) >> >>> The bad of it is that it will increase the number of CSEs. (If under >>> the current scheme there are N audio CSEs and M video CSEs (total >>> N+M) then under this new approach there would be N*M CSEs, and each >>> would be >>> bigger.) But for common cases this may still be manageable. >> Another way would be to keep them separate, but assign an identifier >> for each CSE, and then e.g. in each video CSE list the identifiers of >> all audio CSEs that can be used with that particular video CSE. >> >> Regards, >> >> Christer >> >> >> _______________________________________________ >> 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 spromano@unina.it Fri Mar 8 08:01:01 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 CFCB221F87DF for ; Fri, 8 Mar 2013 08:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZfbKfYd3Lw7 for ; Fri, 8 Mar 2013 08:00:56 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 52BDB21F85BF for ; Fri, 8 Mar 2013 08:00:56 -0800 (PST) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r28G0r8u018208 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Mar 2013 17:00:54 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_EA43F723-7006-4908-80B1-11EF814B179A" Date: Fri, 8 Mar 2013 17:00:53 +0100 Message-Id: <24BA5352-DD8A-4986-924F-52AB9A353EDC@unina.it> To: clue@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [clue] New version of the data model draft available for download 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, 08 Mar 2013 16:01:01 -0000 --Apple-Mail=_EA43F723-7006-4908-80B1-11EF814B179A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear cluers, at the following URL: = http://www.grid.unina.it/Didattica/RetiDiCalcolatori/inf/draft-presta-clue= -data-model-schema-03.html you can find the unofficial -03 version of the data model draft. It took = us some time to write this new version because we tried to be as = complete as possible with respect to the definition/explanation of the = data model elements. See you all in Orlando for a fruitful series of CLUE meetings! Simon (and Roberta, who will be joining us remotely) _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_EA43F723-7006-4908-80B1-11EF814B179A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = cluers,

at the following = URL:


you can find the unofficial -03 version of the data = model draft. It took us some time to write this new version because we = tried to be as complete as possible with respect to the = definition/explanation of the data model = elements.

See you all in Orlando for a fruitful = series of CLUE meetings!

Simon (and Roberta, = who will be joining us remotely)

      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_EA43F723-7006-4908-80B1-11EF814B179A-- From pkyzivat@alum.mit.edu Fri Mar 8 08:01:01 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 CDD5021F87D7 for ; Fri, 8 Mar 2013 08:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.034 X-Spam-Level: X-Spam-Status: No, score=0.034 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=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 EyrZMELrHrcj for ; Fri, 8 Mar 2013 08:00:59 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id B4F4E21F87BB for ; Fri, 8 Mar 2013 08:00:57 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta04.westchester.pa.mail.comcast.net with comcast id 90GN1l00227AodY5440wE1; Fri, 08 Mar 2013 16:00:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id 940w1l00n3ZTu2S3f40wut; Fri, 08 Mar 2013 16:00:56 +0000 Message-ID: <513A0B38.1090309@alum.mit.edu> Date: Sat, 09 Mar 2013 00:00:56 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> <5138F39E.5060204@alum.mit.edu> <51395C0F.2010201@nteczone.com> In-Reply-To: <51395C0F.2010201@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=1362758456; bh=DSek4KoVi6ejigIggxrN4qCoLqpfQUXR3osdkqAZndM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B58SxL4TM+9GnwhkN1QvyueQPUjwIDV9CqSBx2cS6sJ9wWJ+/kx/d0d3Qwzk3InIn H4X+IYA7XOVQM0cnhHl3jBizZHwPoBiAelV2yUH9qNT0J5sGVxX8ebx5dB9zImYnz5 xz3XntLtXOSB17WNvmYgHej6EGI7YLNOSmrtnXKXSx27rwfcd48ECT03jK5exOrCpd HS0XIMbtIVRUdGUY3jtUMt3s6UzgOWYRid5AA5JUl8xDp6Lt2g5RKj9llohJLJmQrS ooW4fwu9H5IJfOjK1+V39C8FH3yK/7W/Gzep1ZSI1L+kcpHSrL0etGeLLPh3F0PM78 2LqvRRXe66efw== Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 08 Mar 2013 16:01:01 -0000 Hi Christian, On 3/8/13 11:33 AM, Christian Groves wrote: > Hello, > > I think part of the problem may be that when people talk about "CLUE" > they actually mean different things. > > For me there's two aspects: 1) CLUE as a signalling protocol, and 2) how > to use CLUE in a SIP network. OK. I'll agree with you that these are conceptually different things, and that we we have not been keeping them distinct. I think one reason is that we aren't entirely sure where to draw the line between them. > For 1) I can't see any need to incorporate SDP into the CLUE signalling. AFAIK nobody is proposing the "incorporate SDP into the CLUE signaling". But we are considering omitting some things from the CLUE signaling because they will instead be signaled in SDP. And also, there is a need to couple the CLUE signaling to the SDP - at least to correlate a capture-encoding in a Configure to an m-line in the SDP. (And maybe some correlation between the Advertisement and the SDP as well.) > For 2) SDP will be required in SIP networks to establish the CLUE data > channel. SDP will also be required to establish the media. > > It would be good for people to clarify what they mean when they are > talking about SDP. AFAIK SDP is well defined - except when we are talking about hypothetical extensions to it. > I personally think the RTCWEB work is a distraction It is distracting, but IMO it is an important and relevant distraction. We don't want the two groups to invent two new wheels when one would do. And we want clue to be able to work with RTCWEB endpoints. As messy as it has become, ISTM that the two groups are exploring a similar set of new functionalities for RTP from different perspectives. I have hope that this will lead to a clearer understanding than if we did it independently. > and likewise the > RTPMUX work for the CLUE signalling protocol. RTPMUX is important for > the establishment of media. I don't understand your point here. You are saying the RTPMUX is important but its a distraction??? Thanks, Paul > Regards, Christian > > On 8/03/2013 7:07 AM, Paul Kyzivat wrote: >> (as individual) >> >> Perhaps we should talk in rtcweb about what we are doing in clue, and >> suggest that some of the understanding of what the multiple streams >> *mean* in rtcweb should be left as application-specific. >> >> Thanks, >> Paul >> >> On 3/8/13 3:48 AM, Mary Barnes wrote: >>> On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg >>> wrote: >>>> >>>> Hi, >>>> >>>> I agree with Paul. >>>> >>>> My personal starting point is still that the CLUE signalling should >>>> be used for the telepresence application related stuff, like spatial >>>> relationship etc. >>>> >>>> I also don't think that the RTCWEB outcome affect us, as far as our >>>> mechanism is concerned. However, if RTCWEB loses interest in pushing >>>> for SDP and/or RTP extensions that we also are interested in, WE may >>>> have to become more active in that work. >>> [MB] >>> I wasn't suggesting that their decision as to the >>> mechanism would directly impact CLUE. I'm suggesting that some of the >>> challenges they are having are due to the fact that they are trying to >>> use SDP for something that it really wasn't designed or envisioned to >>> be used for. I do believe that some of the issues with SDP that they >>> are encountering that is making folks rethink the RTCWEB decision are >>> not unlike those that CLUE may have to deal with. I strongly believe >>> that decoupling the CLUE application from SDP as much as possible is a >>> better path than trying to put so much into SDP (which is a *similar* >>> discussion as is happening in RTCWEB in terms of decoupling the API >>> from SDP). I understand that we are using SIP for session setup, so >>> of course, we will need to use SDP O/A and thus we can't totally >>> decouple. As we have been discussing for well over a year, the >>> challenge is how much of the CLUE application information should be >>> carried in SDP versus a CLUE specific protocol. >>> >>> >>> We should already be more active in the work and not >>> expect that we would just use what RTCWEB needs. CLUE requirements >>> should be considered equal to those of RTCWEB. I think we also need >>> to be very thoughtful as to how we make our decisions so we don't end >>> up a year from now with folks questioning the path we chose. >>> >>> >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> ________________________________________ >>>> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of >>>> Paul Kyzivat [pkyzivat@alum.mit.edu] >>>> Sent: Thursday, 07 March 2013 9:12 PM >>>> To: Mary Barnes >>>> Cc: CLUE >>>> Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model >>>> >>>> I don't fully agree with Mary on this. >>>> >>>> First, I don't think that discussion in RTCWEB has much bearing on >>>> CLUE. >>>> RTCWEB uses a non-sip signaling model. And it doesn't even call for use >>>> of SDP in signaling. Rather it only uses SDP for communication between >>>> the javascript and the browser it runs in. It doesn't require that the >>>> SDP constructed in one broswer be identical to that seen in the browser >>>> at the other end. SDP has long been a poor choice for the purpose we >>>> use >>>> it, but we have legacy reasons to continue and efforts to move to SDPng >>>> failed. It is extremely poor as an abstract conceptual representation >>>> for an API. So IMO it makes sense to think hard about whether to use it >>>> in RTCWEB. The argument there is not what to put in SDP and what to do >>>> another way, it is about whether to use SDP or not. >>>> >>>> But CLUE is mostly SIP-based. We are going to be using SDP. For us the >>>> question is how much to put in SDP and how much to put in the CLUE >>>> protocol. I don't think the rtcweb arguments are helpful about that. >>>> >>>> IMO we should use SDP for the things it does, and perhaps extend it a >>>> bit for things it *ought* to do, philosophically. SDP O/A is focused on >>>> two ends negotiating based on what each is prepared to receive. >>>> Sometimes it talks about what is to be sent, but it isn't so good about >>>> that. In the end the result of the negotiation defines characteristics >>>> of what *will* be sent. And that part is important to some middle >>>> boxes, >>>> so we should try hard not to break that. >>>> >>>> Clue is focused on presenting a menu of what *could* be *sent* and then >>>> selecting from that menu what should be sent, and how. It is pretty >>>> hard >>>> to work out what SDP is required until all that is known. So I prefer >>>> keeping the division that way - the SDP is only used to signal the >>>> details to support what will be sent, based on what was agreed in the >>>> clue signaling. >>>> >>>> In some cases this may lead to conflicts. For instance, SDP has the >>>> a=content attribute. In our clue data model and signaling we will >>>> have a >>>> much richer mechanism to describe similar characteristics. IMO we >>>> should >>>> not feel a need to exclusively use SDP for this. I don't know that we >>>> need to use it at all between clue-aware endpoints, though we ought to >>>> do as much as we can when talking to legacy endpoints. >>>> >>>> So in practice I will probably agree with Mary most of the time about >>>> what should be in SDP and what should not. >>>> >>>> I'll also observe that the less we depend on SDP the less trouble we >>>> will have making CLUE work in RTCWEB. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 3/8/13 2:08 AM, Mary Barnes wrote: >>>>> I really think CLUE folks need to read this thread and understand >>>>> the issues: >>>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html >>>>> >>>>> While we aren't defining an API, we are defining a application. I >>>>> think it's important to carefully consider the tradeoffs in terms of >>>>> how much is carried in SDP versus how much we can do with a CLUE >>>>> specific protocol. >>>>> >>>>> >>>>> I really, really think that the more we put in SDP, the less >>>>> extensibility we will have for the CLUE application - I think we >>>>> really, really need to carefully weigh the tradeoffs between tightly >>>>> coupling the CLUE application to SDP versus minimizing the >>>>> interactions and duplication of information. >>>>> >>>>> In one sense, this is a similar problem we faced with SIP >>>>> conferencing. We defined some basic extensions that worked just fine. >>>>> But, it would have been a bear to add all the additional functionality >>>>> for complex scenarios to SIP. Instead, we defined XCON, which >>>>> decouples the conferencing application from the session >>>>> setup/signaling protocol. XCON is highly extensible and flexible and >>>>> provides a rich set of application functionality. I believe we want >>>>> to same with CLUE a >>>>> >>>>> >>>>> >>>>> Mary. >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Fri Mar 8 08:34:16 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 47A8421F859D for ; Fri, 8 Mar 2013 08:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.263 X-Spam-Level: X-Spam-Status: No, score=-0.263 tagged_above=-999 required=5 tests=[AWL=0.174, 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 4gEVtp1JPbqm for ; Fri, 8 Mar 2013 08:34:12 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 2087221F8540 for ; Fri, 8 Mar 2013 08:34:11 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta01.westchester.pa.mail.comcast.net with comcast id 92AF1l0040QuhwU514a8sl; Fri, 08 Mar 2013 16:34:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 94a71l00k3ZTu2S3N4a7od; Fri, 08 Mar 2013 16:34:08 +0000 Message-ID: <513A12FF.5030002@alum.mit.edu> Date: Sat, 09 Mar 2013 00:34:07 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <24BA5352-DD8A-4986-924F-52AB9A353EDC@unina.it> In-Reply-To: <24BA5352-DD8A-4986-924F-52AB9A353EDC@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1362760448; bh=PLrNVo1Rgpayrr+5zBIWWjyVqkNRACt/IMRb/K6iEOg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qjt75JCTrhScUqJHSp53Ebt/luXNJez4kT5wG8e8LjOBPCEjJ/d1PeCJ7zYSaQR6C vM4oFWLn9XAml6I+4qTOyBHUSCJPaNgGua2zX0OXo1SXb80PdCIA21R0dyDydmop7g FXruKg4vEGkPknm6rQ+/ZdLgR9j4E8Rw8ViaTvtfXdscTnGaIxvoKv45AjCfWjIdHH J9Oi+yKblNqKoIt9C4LxMazF7xTIU5R7fYAMpFY1j3HrV26nIv+noU3B2+mkgB2gMY ksWXzWxZnR+8MxmcPr6o9XhjEaQqoLZ0ApGtuAuXD9nDBlyDugZXRVWxNSe96/wFsn F9DNvc19x9apQ== Subject: Re: [clue] New version of the data model draft available for download 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, 08 Mar 2013 16:34:16 -0000 Simon, Do you have a .txt version, or a diff, so we can see how this has changed from the prior one? Or is it so different that a diff is useless? Thanks, Paul On 3/9/13 12:00 AM, Simon Pietro Romano wrote: > Dear cluers, > > at the following URL: > > http://www.grid.unina.it/Didattica/RetiDiCalcolatori/inf/draft-presta-clue-data-model-schema-03.html > > you can find the unofficial -03 version of the data model draft. It took > us some time to write this new version because we tried to be as > complete as possible with respect to the definition/explanation of the > data model elements. > > See you all in Orlando for a fruitful series of CLUE meetings! > > Simon (and Roberta, who will be joining us remotely) > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From eckelcu@cisco.com Sun Mar 10 17:21: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 EA4D821F8884 for ; Sun, 10 Mar 2013 17:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULDcOVpYY49z for ; Sun, 10 Mar 2013 17:21:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0635421F860A for ; Sun, 10 Mar 2013 17:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3645; q=dns/txt; s=iport; t=1362961288; x=1364170888; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=N7IywhUABaelGKueeJjAZmE5LcrpcI042ERq9fqgRwo=; b=Ty1Dq4jQ/C+K6ENuoYcCEpCuUTaQJZVA+f/F9TB2ICF7jODQynwqDszd Iket7kN5esoVV+K9LcZ8vpWaxcF8Hy0Y6SB7mf/I6dZDCqxwf39yg1mH1 DeVuSItKvWGt83jfjLqEzWtld2XYqqCmJx9wOf9WnBrF5mMgCVRdFqam4 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANQiPVGtJV2b/2dsb2JhbABDxEeBTRZ0giYBAQEEAQEBNy4GFwQCAQgOAwQBAQsUCQcnCxQJCAIEARIIARKHeAy7bI1NgRAmEgaCWWEDklaFHY9XgwqBczU X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185924828" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 11 Mar 2013 00:21:27 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2B0LRuZ022939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 00:21:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 19:21:27 -0500 From: "Charles Eckel (eckelcu)" To: Roni Even , "'Mary Barnes'" , "'CLUE'" Thread-Topic: [clue] CLUE Design Team meeting on for today - March 4th Thread-Index: AQHOGPJ2c8pfmqoDBku99gZdNL/bqJiZxPqAgACNOwCABRsO0A== Date: Mon, 11 Mar 2013 00:21:26 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047CBFAF@xmb-aln-x08.cisco.com> References: <05d601ce1b0f$c4399310$4cacb930$@gmail.com> In-Reply-To: <05d601ce1b0f$c4399310$4cacb930$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 00:21:29 -0000 Hi Roni, I had a look at your draft, and I like it. I think it aligned well with dra= ft-jennings-rtcweb-plan-01, and I agree with your recommendation in 6.2 for= one or multiple RTP streams as well as your assessment at the end of sect= ion 3 that needing to convey all SSRCs in SDP will not scale well for large= conferences. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Roni Even > Sent: Thursday, March 07, 2013 12:43 AM > To: 'Mary Barnes'; 'CLUE' > Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th >=20 > Hi, > I am sorry I missed the meeting. > On the SDP subject > Jonathan, Qin and I submitted a document to MMUSIC > http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-02 that > tries > to address also the CLUE concerns. > It will also be discussed in the MMUSIC session as well as the one you > mentioned http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 > This topic was discussed in the MMUSIC interim meeting and it is importan= t > that the CLUE input should be addressed, please try to attend also the > MMUSIC sessions (Tuesday and Friday (following AVText) > Roni >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Mary > Barnes > Sent: 07 March, 2013 2:17 AM > To: CLUE > Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th >=20 > Hi all, >=20 > Here is a summary of Monday's meeting. >=20 > Attendees: Mary Barnes, Mark Duckworth, Rob Hansen, Paul Kyzivat, Simon > Pietro-Romano >=20 > Notes: > --------- > The objective of the meeting was to review the plans and areas of focus f= or > IETF-86. >=20 > Framework: > - with regards to Stephan's portion on the agenda, the expectation was to > get an update on the rework and way forward. >=20 > - we discussed the incorporation of Christian's suggestions (per the > discussion of draft ) into the framework. Action: Mark to review and > determine if/what changes are required for the framework >=20 > - Mark noted that there are some issues in the tracker that should be > closed. Action: chairs review emails and close related issues >=20 > - Simultaneous sets: it appears the discussion on the list is converging. > Mark: review and determine framework impacts. >=20 > - Paul noted that Stephan had sent an email on FW issues, most of which > really need to be resolved in solution documents >=20 > Signaling/solution: > - Note that Jonathan has produced a draft which was a result of the actio= n > item from IETF-85 for the RTCWEB/CLUE folks to work together for a model > for > RTP: > http://www.ietf.org/id/draft-lennox-raiarea-rtp-grouping-taxonomy-00.txt >=20 > - In terms of the Signaling portion of the agenda on Tuesday, Paul will > provide an overview/update on the current signaling solution document. > That > will lead into Rob's draft specifically analyzing SDP usage. >=20 > Also, folks should read this document which identifies requirements some > of > which are applicable to CLUE: > http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 >=20 > It is on the MMUSIC WG agenda for discussion on Friday: > https://datatracker.ietf.org/meeting/86/agenda/mmusic/ >=20 > Regards, > Mary. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From eckelcu@cisco.com Sun Mar 10 17:21:47 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 4F23621F8884 for ; Sun, 10 Mar 2013 17:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60Ypid-ub31m for ; Sun, 10 Mar 2013 17:21:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A6C8521F860A for ; Sun, 10 Mar 2013 17:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2699; q=dns/txt; s=iport; t=1362961306; x=1364170906; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Cdz+c6XYGXW2kcA5mxtPjTWNz5bbZWFEZ4yPxCjPGvE=; b=UBcIocQC/D7o0JOl8y7tiNwDneNYBM3EuVzJvv1g6qvWRY5Dq+RwoE6s ibvWxsR+v3LiN2RT6BWnhQz36LOUT07ZizgQMfcu4LSxlATZPN/HyAa3e 2ipI3Z24A9Ize4rw/FbXwHaitbY9djL3y151zIIatqqvsxVa9ky48H/TX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAwjPVGtJXG//2dsb2JhbABDxEeBTRZ0giYBAQEDATpLBAIBCBEEAQELFAkHMhQJCAEBBAESCIgFBgy7bIl4g1+BBjgGgllhA5dzj1eDCoFqPg X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="182900789" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 11 Mar 2013 00:21:27 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2B0LRQv029287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 00:21:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 19:21:27 -0500 From: "Charles Eckel (eckelcu)" To: Christer Holmberg , Roni Even , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkAAN77WAAAWGH4AAnOXNIA== Date: Mon, 11 Mar 2013 00:21:26 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047CBFA9@xmb-aln-x08.cisco.com> References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.117.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 00:21:47 -0000 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: Thursday, March 07, 2013 3:32 AM > To: Roni Even; clue@ietf.org > Subject: Re: [clue] Active speaker a role? >=20 > Hi, >=20 >=20 >=20 > >This is a point I made in the past that for switched capture it may be g= ood > to know what is the policy, can be active speaker, time switch (round rob= in) > or other methods. >=20 >=20 >=20 > Correct. So, the question is whether that policy can be seen as a "role". >=20 >=20 >=20 > There could also be "2nd recent speaker", "3rd recent speaker" etc, but > instead of defining a separate role for each of them, maybe we could have > an attribute value, e.g. "recent-speaker=3D2". How about addressing this using something similar to the multiple-render at= tribute proposed in: http://tools.ietf.org/id/draft-jennings-rtcweb-plan-01.txt In this case, you would have the role of active speaker and multiple-render= =3D3, or however many active speakers can be sent/received. Cheers, Charles =20 >=20 >=20 > This type of functionality is very important for devices with a limited > number of streams, screens etc - it non-telepresence rooms. >=20 >=20 >=20 > >As for your second question advertisement is what can be sent, you > probably meant that the configure message should allow to select a specif= ic > switch policy, I think that the configure can only ask for something that= was > advertised >=20 >=20 >=20 > Yes. >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christer Holmberg > Sent: 07 March, 2013 10:19 AM > To: clue@ietf.org > Subject: [clue] Active speaker a role? >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > A couple of questions related to the capture attribute draft. >=20 >=20 >=20 > Q1. >=20 >=20 >=20 > Assume you have a MCU, which collects streams from multiple endpoints, > and provides the active speaker to a single screen entity. So, the conten= t > will change as the most active changes, but the capture provided by the > MCU will be the same. >=20 >=20 >=20 > So, the "role" of this capture would be "active speaker". Or? >=20 >=20 >=20 >=20 >=20 > Q2. >=20 >=20 >=20 > I assume that capture attribute can also be used during the advertisement > phase. Ie a single entity can indicate that it is able to receive a strea= m, > where it want the content to be the "active speaker" role. Or? >=20 >=20 >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 From ron.even.tlv@gmail.com Sun Mar 10 17:51:31 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 E04C821F88ED for ; Sun, 10 Mar 2013 17:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzCW-Jh7fr8X for ; Sun, 10 Mar 2013 17:51:31 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3F921F88E6 for ; Sun, 10 Mar 2013 17:51:31 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id um15so3141696pbc.28 for ; Sun, 10 Mar 2013 17:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=WOpmzMh8wXCIra67hkk8m+eWPMuG7r8F5OMBvTr8h9w=; b=iACcdBbYBRyqxNKnWgj2MqjbRlggwSBQo26hBfG8f1iuSXqfeL2GaThfpZfoIRO0Qi KkEeRWY8Zs01daEZEFjQ2DjHLxl5L9vwSY5CTule8M3bryHQCrTkoc6O3A3BKt0haLZP DWD0dj6rfYorPrKx0Qu5XrL3R4NYZBUBNWPDG9HCOASbEyd3u8dz7+t/h44ny5iLby4G ikJ7i6lhulFuM4bA310omB9UmE0VW25ExpxUV/6GM9wkzETRb7kKAQ1Egny9ujzn2IR5 ob79C6b0gRVU+Kc70rsUvdDkV2CILpbqumSYtP8o60zq5VscLBcAaEZnvI+BoOpAyluM BcLw== X-Received: by 10.68.135.38 with SMTP id pp6mr23656636pbb.111.1362963090600; Sun, 10 Mar 2013 17:51:30 -0700 (PDT) Received: from RoniE ([2001:df8:0:64:d60:a41c:23ae:bacb]) by mx.google.com with ESMTPS id ti8sm17712656pbc.12.2013.03.10.17.51.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 10 Mar 2013 17:51:29 -0700 (PDT) From: "Roni Even" To: "'Charles Eckel \(eckelcu\)'" , "'Mary Barnes'" , "'CLUE'" References: <05d601ce1b0f$c4399310$4cacb930$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CBFAF@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047CBFAF@xmb-aln-x08.cisco.com> Date: Mon, 11 Mar 2013 02:51:05 +0200 Message-ID: <009301ce1df2$853be830$8fb3b890$@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: AQIuk0EuC3Jd73dnk4xtAazIa2roxgJaeGs1Ap0OHRYCUP71p5ekeaNw Content-Language: en-us Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 00:51:32 -0000 Charles, When reading Cullen's draft I also thought so but had a problem when reading the first bullet in section 7. There are some other minor issues like the SSRC usage in the different topologies. Roni -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 11 March, 2013 2:21 AM To: Roni Even; 'Mary Barnes'; 'CLUE' Subject: RE: [clue] CLUE Design Team meeting on for today - March 4th Hi Roni, I had a look at your draft, and I like it. I think it aligned well with draft-jennings-rtcweb-plan-01, and I agree with your recommendation in 6.2 for one or multiple RTP streams as well as your assessment at the end of section 3 that needing to convey all SSRCs in SDP will not scale well for large conferences. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Roni Even > Sent: Thursday, March 07, 2013 12:43 AM > To: 'Mary Barnes'; 'CLUE' > Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th > > Hi, > I am sorry I missed the meeting. > On the SDP subject > Jonathan, Qin and I submitted a document to MMUSIC > http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-02 that > tries to address also the CLUE concerns. > It will also be discussed in the MMUSIC session as well as the one you > mentioned http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 > This topic was discussed in the MMUSIC interim meeting and it is > important that the CLUE input should be addressed, please try to > attend also the MMUSIC sessions (Tuesday and Friday (following > AVText) Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Mary Barnes > Sent: 07 March, 2013 2:17 AM > To: CLUE > Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th > > Hi all, > > Here is a summary of Monday's meeting. > > Attendees: Mary Barnes, Mark Duckworth, Rob Hansen, Paul Kyzivat, > Simon Pietro-Romano > > Notes: > --------- > The objective of the meeting was to review the plans and areas of > focus for IETF-86. > > Framework: > - with regards to Stephan's portion on the agenda, the expectation was > to get an update on the rework and way forward. > > - we discussed the incorporation of Christian's suggestions (per the > discussion of draft ) into the framework. Action: Mark to review and > determine if/what changes are required for the framework > > - Mark noted that there are some issues in the tracker that should be > closed. Action: chairs review emails and close related issues > > - Simultaneous sets: it appears the discussion on the list is converging. > Mark: review and determine framework impacts. > > - Paul noted that Stephan had sent an email on FW issues, most of > which really need to be resolved in solution documents > > Signaling/solution: > - Note that Jonathan has produced a draft which was a result of the > action item from IETF-85 for the RTCWEB/CLUE folks to work together > for a model for > RTP: > http://www.ietf.org/id/draft-lennox-raiarea-rtp-grouping-taxonomy-00.t > xt > > - In terms of the Signaling portion of the agenda on Tuesday, Paul > will provide an overview/update on the current signaling solution document. > That > will lead into Rob's draft specifically analyzing SDP usage. > > Also, folks should read this document which identifies requirements > some of which are applicable to CLUE: > http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 > > It is on the MMUSIC WG agenda for discussion on Friday: > https://datatracker.ietf.org/meeting/86/agenda/mmusic/ > > Regards, > Mary. > _______________________________________________ > 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 eckelcu@cisco.com Sun Mar 10 19:31:21 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 95E5821F89C3 for ; Sun, 10 Mar 2013 19:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUtCmBokI67d for ; Sun, 10 Mar 2013 19:31:16 -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 76A9321F89C7 for ; Sun, 10 Mar 2013 19:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4729; q=dns/txt; s=iport; t=1362969076; x=1364178676; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xOYsGQPvzKbPyOYjWpCTiQCAhSjNvsOF7pS+wAax3+0=; b=is1cPTAb9sD4F3Jmw91naDUkEOn/Jv3lW/9zbNoTzYPfE+vbbNRbJFuj 2Xpo3xGgJG84mMt6HohFDuya7mIf8cMtwJGlP5bGsCAOg5i1RXG2nQ/1y rNJKuV2jqjgEpva+UMdIUkoBrsnexAlAosWAg4dsjtqQTHP3roXc8XDxe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALxBPVGtJXG+/2dsb2JhbABDxEuBTxZ0giQBAQEDAQEBATcuBhcEAgEIDgMEAQELFAkHIQYLFAkIAgQBEggBEodmAwkGDLIdDYlbjEaBB4EQJhIGgllhA5R1gn6KPoUZgwqBczU X-IronPort-AV: E=Sophos;i="4.84,819,1355097600"; d="scan'208";a="185705058" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 11 Mar 2013 02:31:01 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2B2V1nc027773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Mar 2013 02:31:01 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Sun, 10 Mar 2013 21:31:01 -0500 From: "Charles Eckel (eckelcu)" To: Roni Even , "'Mary Barnes'" , "'CLUE'" Thread-Topic: [clue] CLUE Design Team meeting on for today - March 4th Thread-Index: AQHOGPJ2c8pfmqoDBku99gZdNL/bqJiZxPqAgACNOwCABRsO0IAAma6A///HdNA= Date: Mon, 11 Mar 2013 02:31:01 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047CC1A7@xmb-aln-x08.cisco.com> References: <05d601ce1b0f$c4399310$4cacb930$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CBFAF@xmb-aln-x08.cisco.com> <009301ce1df2$853be830$8fb3b890$@gmail.com> In-Reply-To: <009301ce1df2$853be830$8fb3b890$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.85.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 02:31:21 -0000 Yes, I had a similar thought. I think (1) could be modified to be like (3),= saying that " it MUST use separate m-blocks for each unless explicitly sig= naled to be otherwise (see Section 7.2). Cheers, Charles > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Sunday, March 10, 2013 8:51 PM > To: Charles Eckel (eckelcu); 'Mary Barnes'; 'CLUE' > Subject: RE: [clue] CLUE Design Team meeting on for today - March 4th >=20 > Charles, > When reading Cullen's draft I also thought so but had a problem when > reading > the first bullet in section 7. > There are some other minor issues like the SSRC usage in the different > topologies. > Roni >=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 11 March, 2013 2:21 AM > To: Roni Even; 'Mary Barnes'; 'CLUE' > Subject: RE: [clue] CLUE Design Team meeting on for today - March 4th >=20 > Hi Roni, >=20 > I had a look at your draft, and I like it. I think it aligned well with > draft-jennings-rtcweb-plan-01, and I agree with your recommendation in 6.= 2 > for one or multiple RTP streams as well as your assessment at the end of > section 3 that needing to convey all SSRCs in SDP will not scale well for > large conferences. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Roni Even > > Sent: Thursday, March 07, 2013 12:43 AM > > To: 'Mary Barnes'; 'CLUE' > > Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th > > > > Hi, > > I am sorry I missed the meeting. > > On the SDP subject > > Jonathan, Qin and I submitted a document to MMUSIC > > http://tools.ietf.org/html/draft-even-mmusic-multiple-streams-02 that > > tries to address also the CLUE concerns. > > It will also be discussed in the MMUSIC session as well as the one you > > mentioned http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 > > This topic was discussed in the MMUSIC interim meeting and it is > > important that the CLUE input should be addressed, please try to > > attend also the MMUSIC sessions (Tuesday and Friday (following > > AVText) Roni > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Mary Barnes > > Sent: 07 March, 2013 2:17 AM > > To: CLUE > > Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th > > > > Hi all, > > > > Here is a summary of Monday's meeting. > > > > Attendees: Mary Barnes, Mark Duckworth, Rob Hansen, Paul Kyzivat, > > Simon Pietro-Romano > > > > Notes: > > --------- > > The objective of the meeting was to review the plans and areas of > > focus for IETF-86. > > > > Framework: > > - with regards to Stephan's portion on the agenda, the expectation was > > to get an update on the rework and way forward. > > > > - we discussed the incorporation of Christian's suggestions (per the > > discussion of draft ) into the framework. Action: Mark to review and > > determine if/what changes are required for the framework > > > > - Mark noted that there are some issues in the tracker that should be > > closed. Action: chairs review emails and close related issues > > > > - Simultaneous sets: it appears the discussion on the list is convergin= g. > > Mark: review and determine framework impacts. > > > > - Paul noted that Stephan had sent an email on FW issues, most of > > which really need to be resolved in solution documents > > > > Signaling/solution: > > - Note that Jonathan has produced a draft which was a result of the > > action item from IETF-85 for the RTCWEB/CLUE folks to work together > > for a model for > > RTP: > > http://www.ietf.org/id/draft-lennox-raiarea-rtp-grouping-taxonomy-00.t > > xt > > > > - In terms of the Signaling portion of the agenda on Tuesday, Paul > > will provide an overview/update on the current signaling solution > document. > > That > > will lead into Rob's draft specifically analyzing SDP usage. > > > > Also, folks should read this document which identifies requirements > > some of which are applicable to CLUE: > > http://tools.ietf.org/html/draft-jennings-rtcweb-plan-01 > > > > It is on the MMUSIC WG agenda for discussion on Friday: > > https://datatracker.ietf.org/meeting/86/agenda/mmusic/ > > > > Regards, > > Mary. > > _______________________________________________ > > 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 ietf@meetecho.com Sun Mar 10 20:35:00 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 4905B21F862B for ; Sun, 10 Mar 2013 20:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO6YjTjaQMy7 for ; Sun, 10 Mar 2013 20:34:59 -0700 (PDT) Received: from smtpdg11.aruba.it (smtpdg95.aruba.it [62.149.158.95]) by ietfa.amsl.com (Postfix) with ESMTP id 25F1021F866E for ; Sun, 10 Mar 2013 20:34:58 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd05.ad.aruba.it with bizsmtp id A3ao1l00V0wzZHu013aqk9; Mon, 11 Mar 2013 04:34:51 +0100 Date: Sun, 10 Mar 2013 23:34:19 -0700 (PDT) From: Meetecho Team To: clue@ietf.org Message-ID: <7635991.1.1362983659123.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_33449859.1362983659112" Subject: [clue] Meetecho support for CLUE session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 03:35:00 -0000 ------=_Part_0_33449859.1362983659112 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the CLUE WG meeting session. Access to the on-line session (including audio and video streams) will be available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/clue The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_33449859.1362983659112-- From ietf@meetecho.com Mon Mar 11 10:12:26 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 F315721F8C00 for ; Mon, 11 Mar 2013 10:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.659 X-Spam-Level: X-Spam-Status: No, score=-0.659 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H99Fil9CNbzT for ; Mon, 11 Mar 2013 10:12:25 -0700 (PDT) Received: from smtpdg5.aruba.it (smtpdg223.aruba.it [62.149.158.223]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7621F8BF6 for ; Mon, 11 Mar 2013 10:12:24 -0700 (PDT) Received: from meetecho ([130.129.6.44]) by smtpcmd02.ad.aruba.it with bizsmtp id AHCH1l00R0wzZHu01HCKPK; Mon, 11 Mar 2013 18:12:20 +0100 Date: Mon, 11 Mar 2013 13:11:45 -0700 (PDT) From: Meetecho Team To: clue@ietf.org Message-ID: <31582617.1.1363032705566.JavaMail.root@meetecho> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_13762776.1363032705541" Subject: [clue] CLUE session recording available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:12:26 -0000 ------=_Part_0_13762776.1363032705541 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the CLUE WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#IETF86_CLUE In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_13762776.1363032705541-- From Christian.Groves@nteczone.com Mon Mar 11 15:01: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 37D1F21F9034 for ; Mon, 11 Mar 2013 15:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 2ed4pgPGtZ6S for ; Mon, 11 Mar 2013 15:01:22 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 4415621F9061 for ; Mon, 11 Mar 2013 15:01:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAGJSPlF20b6I/2dsb2JhbAANNsRkgXODHQEBAQQBAQE1GxsLEAsYCSUPAhYwBg0BBQIBAYgbrBCDMZAWBI8OB4NAA6po Received: from ppp118-209-190-136.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.190.136]) by ipmail06.adl2.internode.on.net with ESMTP; 12 Mar 2013 08:31:20 +1030 Message-ID: <513E542D.40209@nteczone.com> Date: Tue, 12 Mar 2013 09:01:17 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <512E54AD.9090707@unina.it> <9C23AB934B394845A7B228239B6EAF416F09B4@CRPMBOXPRD01.polycom.com> <51375D02.5000207@alum.mit.edu> <9C23AB934B394845A7B228239B6EAF416F0B83@CRPMBOXPRD01.polycom.com> <51381D05.3090101@nteczone.com> <061401ce1b31$a124bd10$e36e3730$@gmail.com> <7594FB04B1934943A5C02806D1A2204B114B24@ESESSMB209.ericsson.se>, <5138B68E.6010203@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B114EC2@ESESSMB209.ericsson.se> <5138CAE0.4010103@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B115FD1@ESESSMB209.ericsson.se> <513957A1.20102@nteczone.com> <7594FB04B1934943A5C02806D1A2204B116AA1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B116AA1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] comments to framework 09 - simultaneous sets X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:01:23 -0000 Hello Christer, If there's only one audio capture then there's no real need to assign roles as it's that only choice. However I do take the point that capture could have multiple roles. Regards, Christian On 8/03/2013 10:43 PM, Christer Holmberg wrote: > Hi, > > >From an application level I think the capture attributes should provide a means to select the audio captures. There may or may not be a one to one mapping. For example a video may have multiple audio feeds (i.e. >> different languages). The consumer can chose one or more of these audio feeds. >> >> In the role case there's no reason why both the audio and video captures can't be labelled with the role. >> >> Linking the video and audio captures with an ID could provide more explicit information. The ids would have to be >> consistent with the capture attributes. I guess we could say if these additional Audio CSEs aren't included in the >> Video CSE then it means to use the default behaviour we already defined? > Assume there are two video captures: "Christian" and "Paul". > > Then, there is a single audio capture, which provides audio for both "Christian" and "Paul". > > Now, the role of that audio capture can not be "Christian" alone, and it can not be "Paul" alone. > > Of course, it CAN be "Christian" AND "Paul", if we allow a capture to have multiple roles. Maybe that is already allowed, so my apologies if I've missed it :) > > Regards, > > Christer > > > > On 8/03/2013 4:30 AM, Christer Holmberg wrote: >> Hi, >> >>>>>> Do we assume there is a one-to-one mapping between video and audio captures? >>>>>> >>>>>> For example, assume one video capture has the role "manager". >>>>>> >>>>>> That doesn't mean that there will be an audio capture with the same role, because the audio capture may cover a bigger area, including many persons. >>>>>> >>>>>> So, if I show the manager on my screen, how do I know which audio capture to choose? >>>>> I too have wondered about this, and have no great answer. >>>>> >>>>> The simple answer is use spatial coordinates. But I'm not at all >>>>> convinced that is a complete answer. >>>> Also, you can have multiple video CSEs, and multiple audio CSEs, and the choise of audio CSE may depend on the choise of video CSE. So, is there a reason why we can't put different media types in the same CSE, if they are associated? I think it would help alot. >>>> >>>> But, that still doesn't solve the problem about, though, if you e.g. from a CSE only choose a specific set of video captures, and also want the corresponding audio captures. Maybe spatial coordinates helps there. >>> I agree that this seems to be an issue that deserves more study. >>> Is somebody willing to think hard about it and come back with an analysis? >>> >>> It certainly would be possible to redefine CSEs so that they contain captures of different media types. The good of it is that it mostly solves the problem you present. >> It helps picking CSEs, but it still does not map individual captures >> :) >> >>> The bad of it is that it will increase the number of CSEs. (If under >>> the current scheme there are N audio CSEs and M video CSEs (total >>> N+M) then under this new approach there would be N*M CSEs, and each >>> would be >>> bigger.) But for common cases this may still be manageable. >> Another way would be to keep them separate, but assign an identifier for each CSE, and then e.g. in each video CSE list the identifiers of all audio CSEs that can be used with that particular video CSE. >> >> Regards, >> >> Christer >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Mar 11 15:11: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 6D24C21F8B37 for ; Mon, 11 Mar 2013 15:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtUuSWPYc81T for ; Mon, 11 Mar 2013 15:11:21 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id BDE1621F86CA for ; Mon, 11 Mar 2013 15:11:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAE5VPlF20b6I/2dsb2JhbAANNsRkgXODHQEBAQMBAQEBNRsUBwQGEQsRBAEBAQkWDwkDAgECARUoCBMGAgEBBYgEEqwYgzGQGo1MEYEmEoNAA5JWmBKBXw Received: from ppp118-209-190-136.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.190.136]) by ipmail06.adl2.internode.on.net with ESMTP; 12 Mar 2013 08:41:19 +1030 Message-ID: <513E5684.5010404@nteczone.com> Date: Tue, 12 Mar 2013 09:11:16 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> <5138F39E.5060204@alum.mit.edu> <51395C0F.2010201@nteczone.com> <513A0B38.1090309@alum.mit.edu> In-Reply-To: <513A0B38.1090309@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:11:22 -0000 Hello Paul, Please see my response below. Regards, Christian On 9/03/2013 3:00 AM, Paul Kyzivat wrote: > Hi Christian, > > On 3/8/13 11:33 AM, Christian Groves wrote: >> Hello, >> >> I think part of the problem may be that when people talk about "CLUE" >> they actually mean different things. >> >> For me there's two aspects: 1) CLUE as a signalling protocol, and 2) how >> to use CLUE in a SIP network. > > OK. I'll agree with you that these are conceptually different things, > and that we we have not been keeping them distinct. I think one reason > is that we aren't entirely sure where to draw the line between them. > >> For 1) I can't see any need to incorporate SDP into the CLUE signalling. > > AFAIK nobody is proposing the "incorporate SDP into the CLUE signaling". > > But we are considering omitting some things from the CLUE signaling > because they will instead be signaled in SDP. And also, there is a > need to couple the CLUE signaling to the SDP - at least to correlate a > capture-encoding in a Configure to an m-line in the SDP. (And maybe > some correlation between the Advertisement and the SDP as well.) [CNG] Omitting? IS there something in the framework that is thought can be omitted? > >> For 2) SDP will be required in SIP networks to establish the CLUE data >> channel. SDP will also be required to establish the media. >> >> It would be good for people to clarify what they mean when they are >> talking about SDP. > > AFAIK SDP is well defined - except when we are talking about > hypothetical extensions to it. [CNG] OK my last sentence could have had a few extra words in it. I'm sure people know what SDP is. I was referring to that when people use the term SDP with CLUE it would be good to be more specific, i.e. SDP to correlate captures with stream etc. > >> I personally think the RTCWEB work is a distraction > > It is distracting, but IMO it is an important and relevant distraction. > We don't want the two groups to invent two new wheels when one would do. > And we want clue to be able to work with RTCWEB endpoints. > > As messy as it has become, ISTM that the two groups are exploring a > similar set of new functionalities for RTP from different > perspectives. I have hope that this will lead to a clearer > understanding than if we did it independently. >> and likewise the >> RTPMUX work for the CLUE signalling protocol. RTPMUX is important for >> the establishment of media. > > I don't understand your point here. You are saying the RTPMUX is > important but its a distraction??? [CNG] Yes. The CLUE protocol can/should happily exist without the need for RTPMUX. Of course as the framework points out there are real world limitation on ports. Endpoints implementing CLUE may also want to implement RTPMuxing. We should be able to finish the CLUE work even if RTPmux work is ongoing. > > Thanks, > Paul > >> Regards, Christian >> >> On 8/03/2013 7:07 AM, Paul Kyzivat wrote: >>> (as individual) >>> >>> Perhaps we should talk in rtcweb about what we are doing in clue, and >>> suggest that some of the understanding of what the multiple streams >>> *mean* in rtcweb should be left as application-specific. >>> >>> Thanks, >>> Paul >>> >>> On 3/8/13 3:48 AM, Mary Barnes wrote: >>>> On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I agree with Paul. >>>>> >>>>> My personal starting point is still that the CLUE signalling should >>>>> be used for the telepresence application related stuff, like spatial >>>>> relationship etc. >>>>> >>>>> I also don't think that the RTCWEB outcome affect us, as far as our >>>>> mechanism is concerned. However, if RTCWEB loses interest in pushing >>>>> for SDP and/or RTP extensions that we also are interested in, WE may >>>>> have to become more active in that work. >>>> [MB] >>>> I wasn't suggesting that their decision as to the >>>> mechanism would directly impact CLUE. I'm suggesting that some of the >>>> challenges they are having are due to the fact that they are trying to >>>> use SDP for something that it really wasn't designed or envisioned to >>>> be used for. I do believe that some of the issues with SDP that they >>>> are encountering that is making folks rethink the RTCWEB decision are >>>> not unlike those that CLUE may have to deal with. I strongly believe >>>> that decoupling the CLUE application from SDP as much as possible is a >>>> better path than trying to put so much into SDP (which is a *similar* >>>> discussion as is happening in RTCWEB in terms of decoupling the API >>>> from SDP). I understand that we are using SIP for session setup, so >>>> of course, we will need to use SDP O/A and thus we can't totally >>>> decouple. As we have been discussing for well over a year, the >>>> challenge is how much of the CLUE application information should be >>>> carried in SDP versus a CLUE specific protocol. >>>> >>>> >>>> We should already be more active in the work and not >>>> expect that we would just use what RTCWEB needs. CLUE requirements >>>> should be considered equal to those of RTCWEB. I think we also need >>>> to be very thoughtful as to how we make our decisions so we don't end >>>> up a year from now with folks questioning the path we chose. >>>> >>>> >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> ________________________________________ >>>>> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of >>>>> Paul Kyzivat [pkyzivat@alum.mit.edu] >>>>> Sent: Thursday, 07 March 2013 9:12 PM >>>>> To: Mary Barnes >>>>> Cc: CLUE >>>>> Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model >>>>> >>>>> I don't fully agree with Mary on this. >>>>> >>>>> First, I don't think that discussion in RTCWEB has much bearing on >>>>> CLUE. >>>>> RTCWEB uses a non-sip signaling model. And it doesn't even call >>>>> for use >>>>> of SDP in signaling. Rather it only uses SDP for communication >>>>> between >>>>> the javascript and the browser it runs in. It doesn't require that >>>>> the >>>>> SDP constructed in one broswer be identical to that seen in the >>>>> browser >>>>> at the other end. SDP has long been a poor choice for the purpose we >>>>> use >>>>> it, but we have legacy reasons to continue and efforts to move to >>>>> SDPng >>>>> failed. It is extremely poor as an abstract conceptual representation >>>>> for an API. So IMO it makes sense to think hard about whether to >>>>> use it >>>>> in RTCWEB. The argument there is not what to put in SDP and what >>>>> to do >>>>> another way, it is about whether to use SDP or not. >>>>> >>>>> But CLUE is mostly SIP-based. We are going to be using SDP. For us >>>>> the >>>>> question is how much to put in SDP and how much to put in the CLUE >>>>> protocol. I don't think the rtcweb arguments are helpful about that. >>>>> >>>>> IMO we should use SDP for the things it does, and perhaps extend it a >>>>> bit for things it *ought* to do, philosophically. SDP O/A is >>>>> focused on >>>>> two ends negotiating based on what each is prepared to receive. >>>>> Sometimes it talks about what is to be sent, but it isn't so good >>>>> about >>>>> that. In the end the result of the negotiation defines >>>>> characteristics >>>>> of what *will* be sent. And that part is important to some middle >>>>> boxes, >>>>> so we should try hard not to break that. >>>>> >>>>> Clue is focused on presenting a menu of what *could* be *sent* and >>>>> then >>>>> selecting from that menu what should be sent, and how. It is pretty >>>>> hard >>>>> to work out what SDP is required until all that is known. So I prefer >>>>> keeping the division that way - the SDP is only used to signal the >>>>> details to support what will be sent, based on what was agreed in the >>>>> clue signaling. >>>>> >>>>> In some cases this may lead to conflicts. For instance, SDP has the >>>>> a=content attribute. In our clue data model and signaling we will >>>>> have a >>>>> much richer mechanism to describe similar characteristics. IMO we >>>>> should >>>>> not feel a need to exclusively use SDP for this. I don't know that we >>>>> need to use it at all between clue-aware endpoints, though we >>>>> ought to >>>>> do as much as we can when talking to legacy endpoints. >>>>> >>>>> So in practice I will probably agree with Mary most of the time about >>>>> what should be in SDP and what should not. >>>>> >>>>> I'll also observe that the less we depend on SDP the less trouble we >>>>> will have making CLUE work in RTCWEB. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 3/8/13 2:08 AM, Mary Barnes wrote: >>>>>> I really think CLUE folks need to read this thread and understand >>>>>> the issues: >>>>>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg06612.html >>>>>> >>>>>> While we aren't defining an API, we are defining a application. I >>>>>> think it's important to carefully consider the tradeoffs in terms of >>>>>> how much is carried in SDP versus how much we can do with a CLUE >>>>>> specific protocol. >>>>>> >>>>>> >>>>>> I really, really think that the more we put in SDP, the less >>>>>> extensibility we will have for the CLUE application - I think we >>>>>> really, really need to carefully weigh the tradeoffs between tightly >>>>>> coupling the CLUE application to SDP versus minimizing the >>>>>> interactions and duplication of information. >>>>>> >>>>>> In one sense, this is a similar problem we faced with SIP >>>>>> conferencing. We defined some basic extensions that worked just >>>>>> fine. >>>>>> But, it would have been a bear to add all the additional >>>>>> functionality >>>>>> for complex scenarios to SIP. Instead, we defined XCON, which >>>>>> decouples the conferencing application from the session >>>>>> setup/signaling protocol. XCON is highly extensible and flexible >>>>>> and >>>>>> provides a rich set of application functionality. I believe we want >>>>>> to same with CLUE a >>>>>> >>>>>> >>>>>> >>>>>> Mary. >>>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Mar 11 15:41:13 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 BBF1F21F901E for ; Mon, 11 Mar 2013 15:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.762 X-Spam-Level: X-Spam-Status: No, score=-103.762 tagged_above=-999 required=5 tests=[AWL=-0.163, 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 htoAbQifjsv8 for ; Mon, 11 Mar 2013 15:41:13 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id E461D21F8F06 for ; Mon, 11 Mar 2013 15:41:12 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so1274865qab.14 for ; Mon, 11 Mar 2013 15:41:12 -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 :content-type; bh=/Q4zlwOPD95MroQJgSUp0uTfzoHtQVl+t4FF1SYRu5A=; b=OFaOsrxpcjh92rWQZr8b+qpUrKP1yvqJXetHTUfyHEYN9iRjK8XXnHICbsCmErahDD gbbi20ruY8j/OhGai3lIjHOztTjAW/tEure2nti98jHZQEKUdFj22IUGlufioTm0ud2i dJ9I9HFlO9vjM70CzqvmxetreboKOhIl+g5Njc2EdVaREjJhbP/agGzndfE6HYw8IoUd q7kfbMHNy2BM7sB2d/Bg6Xs+gfpWgrg/pR7SBxjkyxxchul013tm1J0k3jIkTKjqsaro PcNtJFReHBp3zSf3rCa3+4ijPTqQV4vfbRSvWtzpuqGQvLCt14/lhTZqE1aqDal5ty5+ w/sQ== MIME-Version: 1.0 X-Received: by 10.224.27.136 with SMTP id i8mr19692131qac.63.1363041672519; Mon, 11 Mar 2013 15:41:12 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Mon, 11 Mar 2013 15:41:12 -0700 (PDT) Date: Mon, 11 Mar 2013 17:41:12 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] CLUE WG Dinner X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 22:41:13 -0000 Since I had multiple questions on this. For folks that RSVPed to dinner or who have since told me they will attend, the plan is to head over right after the plenary, which is supposed to end at 7:40 but I would not necessarily count on that at this point. http://www.doodle.com/xaqdxztxrpt8h6wq The reservation is at Flemings at 8pm (details are in the doodle). If folks want to leave early (I would if I could ;), that would be fine. Please claim the reservation - Mary Barnes, 12 @8pm. Thanks, Mary. From bill.wu@huawei.com Tue Mar 12 04:40:51 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 4A40A21F8702 for ; Tue, 12 Mar 2013 04:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 We-0RC+OHhWF for ; Tue, 12 Mar 2013 04:40:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43E1021F8675 for ; Tue, 12 Mar 2013 04:40:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQO28478; Tue, 12 Mar 2013 11:40:49 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Mar 2013 11:40:17 +0000 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Mar 2013 11:40:47 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.126]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Tue, 12 Mar 2013 19:40:42 +0800 From: Qin Wu To: "Charles Eckel (eckelcu)" , Christer Holmberg , Roni Even , "clue@ietf.org" Thread-Topic: [clue] Active speaker a role? Thread-Index: Ac4bC+LetL4ZFFrzRZyWuQMoRlpzkP//hMyAgAAsMYCABY3dAP/9K2Og Date: Tue, 12 Mar 2013 11:40:41 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C08828047CBFA9@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047CBFA9@xmb-aln-x08.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [clue] =?gb2312?b?tPC4tDogIEFjdGl2ZSBzcGVha2VyIGEgcm9sZT8=?= 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, 12 Mar 2013 11:40:51 -0000 LS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0Kt6LL zcqxvOQ6IDIwMTPE6jPUwjEwyNUgMjA6MjENCsrVvP7IyzogQ2hyaXN0ZXIgSG9sbWJlcmc7IFJv bmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0K1vfM4jogUmU6IFtjbHVlXSBBY3RpdmUgc3BlYWtlciBh IHJvbGU/DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1ZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YN Cj4gQ2hyaXN0ZXIgSG9sbWJlcmcNCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDA3LCAyMDEzIDM6 MzIgQU0NCj4gVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2Ns dWVdIEFjdGl2ZSBzcGVha2VyIGEgcm9sZT8NCj4gDQo+IEhpLA0KPiANCj4gDQo+IA0KPiA+VGhp cyBpcyBhIHBvaW50IEkgbWFkZSBpbiB0aGUgcGFzdCB0aGF0IGZvciBzd2l0Y2hlZCBjYXB0dXJl IGl0IG1heSBiZSBnb29kDQo+IHRvIGtub3cgd2hhdCBpcyB0aGUgcG9saWN5LCBjYW4gYmUgYWN0 aXZlIHNwZWFrZXIsIHRpbWUgc3dpdGNoIChyb3VuZCByb2JpbikNCj4gb3Igb3RoZXIgbWV0aG9k cy4NCj4gDQo+IA0KPiANCj4gQ29ycmVjdC4gU28sIHRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRo YXQgcG9saWN5IGNhbiBiZSBzZWVuIGFzIGEgInJvbGUiLg0KPiANCj4gDQo+IA0KPiBUaGVyZSBj b3VsZCBhbHNvIGJlICIybmQgcmVjZW50IHNwZWFrZXIiLCAiM3JkIHJlY2VudCBzcGVha2VyIiBl dGMsIGJ1dA0KPiBpbnN0ZWFkIG9mIGRlZmluaW5nIGEgc2VwYXJhdGUgcm9sZSBmb3IgZWFjaCBv ZiB0aGVtLCBtYXliZSB3ZSBjb3VsZCBoYXZlDQo+IGFuIGF0dHJpYnV0ZSB2YWx1ZSwgZS5nLiAi cmVjZW50LXNwZWFrZXI9MiIuDQoNCkhvdyBhYm91dCBhZGRyZXNzaW5nIHRoaXMgdXNpbmcgc29t ZXRoaW5nIHNpbWlsYXIgdG8gdGhlIG11bHRpcGxlLXJlbmRlciBhdHRyaWJ1dGUgcHJvcG9zZWQg aW46DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtamVubmluZ3MtcnRjd2ViLXBsYW4t MDEudHh0DQoNCkluIHRoaXMgY2FzZSwgeW91IHdvdWxkIGhhdmUgdGhlIHJvbGUgb2YgYWN0aXZl IHNwZWFrZXIgYW5kIG11bHRpcGxlLXJlbmRlcj0zLCBvciBob3dldmVyIG1hbnkgYWN0aXZlIHNw ZWFrZXJzIGNhbiBiZSBzZW50L3JlY2VpdmVkLg0KDQpbUWluXTogU29ycnkgdG8gY2hpbWUgaW4s IGl0IGlzIG5vdCBjbGVhciB0byBtZSB3aHkgdGhlIGF0dHJpYnV0ZSBtdWx0aXBsZS1yZW5kZXIg aXMgcmVhbGx5IG5lZWRlZD8gSXMgdGhpcyBhdHRyaWJ1dGVkIHVzZWQgdG8gZGVhbCB3aXRoIHNp bXVsY2FzdCBjYXNlPw0KSXMgIm11bHRpcGxlIHN0cmVhbXMgYXJlIHNlbnQgYXQgdGhlIHNhbWUg dGltZSIgc2FtZSBhcyAibXVsdGlwbGUgc3RyZWFtcyBhcmUgcmVuZGVyZWQgYXQgdGhlIHNhbWUg dGltZSI/DQpXaHkgIiBtYXgtc2VuZC1zc3JjIiBhbmQgIiBtYXgtcmVjdi1zc3JjIiBjYW4gbm90 IGJlIHVzZWQgZm9yIHRoaXMgcHVycG9zZT8NClBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgbWlzcyBz b21ldGhpbmcuDQoNCkNoZWVycywNCkNoYXJsZXMNCiANCj4gDQo+IA0KPiBUaGlzIHR5cGUgb2Yg ZnVuY3Rpb25hbGl0eSBpcyB2ZXJ5IGltcG9ydGFudCBmb3IgZGV2aWNlcyB3aXRoIGEgbGltaXRl ZA0KPiBudW1iZXIgb2Ygc3RyZWFtcywgc2NyZWVucyBldGMgLSBpdCBub24tdGVsZXByZXNlbmNl IHJvb21zLg0KPiANCj4gDQo+IA0KPiA+QXMgZm9yIHlvdXIgc2Vjb25kIHF1ZXN0aW9uIGFkdmVy dGlzZW1lbnQgaXMgd2hhdCBjYW4gYmUgc2VudCwgeW91DQo+IHByb2JhYmx5IG1lYW50IHRoYXQg dGhlIGNvbmZpZ3VyZSBtZXNzYWdlIHNob3VsZCBhbGxvdyB0byBzZWxlY3QgYSBzcGVjaWZpYw0K PiBzd2l0Y2ggcG9saWN5LCBJIHRoaW5rIHRoYXQgdGhlIGNvbmZpZ3VyZSBjYW4gb25seSBhc2sg Zm9yIHNvbWV0aGluZyB0aGF0IHdhcw0KPiBhZHZlcnRpc2VkDQo+IA0KPiANCj4gDQo+IFllcy4N Cj4gDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IENocmlzdGVyIEhvbG1iZXJn DQo+IFNlbnQ6IDA3IE1hcmNoLCAyMDEzIDEwOjE5IEFNDQo+IFRvOiBjbHVlQGlldGYub3JnDQo+ IFN1YmplY3Q6IFtjbHVlXSBBY3RpdmUgc3BlYWtlciBhIHJvbGU/DQo+IA0KPiANCj4gDQo+IEhp LA0KPiANCj4gDQo+IA0KPiBBIGNvdXBsZSBvZiBxdWVzdGlvbnMgcmVsYXRlZCB0byB0aGUgY2Fw dHVyZSBhdHRyaWJ1dGUgZHJhZnQuDQo+IA0KPiANCj4gDQo+IFExLg0KPiANCj4gDQo+IA0KPiBB c3N1bWUgeW91IGhhdmUgYSBNQ1UsIHdoaWNoIGNvbGxlY3RzIHN0cmVhbXMgZnJvbSBtdWx0aXBs ZSBlbmRwb2ludHMsDQo+IGFuZCBwcm92aWRlcyB0aGUgYWN0aXZlIHNwZWFrZXIgdG8gYSBzaW5n bGUgc2NyZWVuIGVudGl0eS4gU28sIHRoZSBjb250ZW50DQo+IHdpbGwgY2hhbmdlIGFzIHRoZSBt b3N0IGFjdGl2ZSBjaGFuZ2VzLCBidXQgdGhlIGNhcHR1cmUgcHJvdmlkZWQgYnkgdGhlDQo+IE1D VSB3aWxsIGJlIHRoZSBzYW1lLg0KPiANCj4gDQo+IA0KPiBTbywgdGhlICJyb2xlIiBvZiB0aGlz IGNhcHR1cmUgd291bGQgYmUgImFjdGl2ZSBzcGVha2VyIi4gT3I/DQo+IA0KPiANCj4gDQo+IA0K PiANCj4gUTIuDQo+IA0KPiANCj4gDQo+IEkgYXNzdW1lIHRoYXQgY2FwdHVyZSBhdHRyaWJ1dGUg Y2FuIGFsc28gYmUgdXNlZCBkdXJpbmcgdGhlIGFkdmVydGlzZW1lbnQNCj4gcGhhc2UuIEllIGEg c2luZ2xlIGVudGl0eSBjYW4gaW5kaWNhdGUgdGhhdCBpdCBpcyBhYmxlIHRvIHJlY2VpdmUgYSBz dHJlYW0sDQo+IHdoZXJlIGl0IHdhbnQgdGhlIGNvbnRlbnQgdG8gYmUgdGhlICJhY3RpdmUgc3Bl YWtlciIgcm9sZS4gT3I/DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IA0K PiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KY2x1ZSBtYWlsaW5nIGxpc3QNCmNsdWVAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From bill.wu@huawei.com Tue Mar 12 04:45:39 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 6A65E21F86C0 for ; Tue, 12 Mar 2013 04:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.549 X-Spam-Level: ** X-Spam-Status: No, score=2.549 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 UeKjfjJwuXJI for ; Tue, 12 Mar 2013 04:45:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDB621F8623 for ; Tue, 12 Mar 2013 04:45:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APH28956; Tue, 12 Mar 2013 11:45:37 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Mar 2013 11:45:05 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Mar 2013 11:45:36 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.126]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Tue, 12 Mar 2013 19:45:32 +0800 From: Qin Wu To: "Charles Eckel (eckelcu)" , Roni Even , "'Mary Barnes'" , "'CLUE'" Thread-Topic: [clue] CLUE Design Team meeting on for today - March 4th Thread-Index: AQHOGPJxn0nTyiC3EUiCZPwHdqnDe5iY2kiAgACNOwCABb04AIAACEiAgAAb7ICAArJKMA== Date: Tue, 12 Mar 2013 11:45:32 +0000 Message-ID: References: <05d601ce1b0f$c4399310$4cacb930$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CBFAF@xmb-aln-x08.cisco.com> <009301ce1df2$853be830$8fb3b890$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CC1A7@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047CC1A7@xmb-aln-x08.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.180] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [clue] =?gb2312?b?tPC4tDogIENMVUUgRGVzaWduIFRlYW0gbWVldGluZyBv?= =?gb2312?b?biBmb3IgdG9kYXkgLSBNYXJjaCA0dGg=?= 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, 12 Mar 2013 11:45:39 -0000 T25lIGNvbmZ1c2lvbiB3aGVuIEkgcmVhZCBjdWxsZW4ncyBkcmFmdCBhYm91dCBNU0lEIHVzYWdl PyBJcyBNU0lEIHVzZWQgdG8gaWRlbnRpZnkgZWFjaCBtZWRpYSBzdHJlYW0gb3IgSXMgTVNJRCB1 c2VkIHRvIGlkZW50aWZ5IGVhY2ggZGV2aWNlIGlkZW50aWZpZXI/DQpJIGNhbiB1bmRlcnN0YW5k IHRoZSBmb3JtZXIgY2FzZSwgc2VlbXMgaXQgaXMgcXVpdGUgc2ltaWxhciB0byBtdWx0aS1jaGFu bmVsIGF1ZGlvIGNhc2UuIEJ1dCBJIGFtIGxvc3Qgd2hlbiBNU0lEIGlzIHJlcHVycG9zZWQgYXMg ZGV2aWNlIGlkZW50aWZpZXIuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0N CreivP7IyzogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYu b3JnXSC0+rHtIENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQq3osvNyrG85DogMjAxM8TqM9TCMTDI 1SAyMjozMQ0KytW8/sjLOiBSb25pIEV2ZW47ICdNYXJ5IEJhcm5lcyc7ICdDTFVFJw0K1vfM4jog UmU6IFtjbHVlXSBDTFVFIERlc2lnbiBUZWFtIG1lZXRpbmcgb24gZm9yIHRvZGF5IC0gTWFyY2gg NHRoDQoNClllcywgSSBoYWQgYSBzaW1pbGFyIHRob3VnaHQuIEkgdGhpbmsgKDEpIGNvdWxkIGJl IG1vZGlmaWVkIHRvIGJlIGxpa2UgKDMpLCBzYXlpbmcgdGhhdCAiIGl0IE1VU1QgdXNlIHNlcGFy YXRlIG0tYmxvY2tzIGZvciBlYWNoIHVubGVzcyBleHBsaWNpdGx5IHNpZ25hbGVkIHRvIGJlIG90 aGVyd2lzZSAoc2VlIFNlY3Rpb24gNy4yKS4NCg0KQ2hlZXJzLA0KQ2hhcmxlcw0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbi5ldmVu LnRsdkBnbWFpbC5jb21dDQo+IFNlbnQ6IFN1bmRheSwgTWFyY2ggMTAsIDIwMTMgODo1MSBQTQ0K PiBUbzogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSk7ICdNYXJ5IEJhcm5lcyc7ICdDTFVFJw0KPiBT dWJqZWN0OiBSRTogW2NsdWVdIENMVUUgRGVzaWduIFRlYW0gbWVldGluZyBvbiBmb3IgdG9kYXkg LSBNYXJjaCA0dGgNCj4gDQo+IENoYXJsZXMsDQo+IFdoZW4gcmVhZGluZyBDdWxsZW4ncyBkcmFm dCBJIGFsc28gdGhvdWdodCBzbyBidXQgaGFkIGEgcHJvYmxlbSB3aGVuDQo+IHJlYWRpbmcNCj4g dGhlIGZpcnN0IGJ1bGxldCBpbiBzZWN0aW9uIDcuDQo+IFRoZXJlIGFyZSBzb21lIG90aGVyIG1p bm9yIGlzc3VlcyBsaWtlIHRoZSBTU1JDIHVzYWdlIGluIHRoZSBkaWZmZXJlbnQNCj4gdG9wb2xv Z2llcy4NCj4gUm9uaQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog Q2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0NCj4gU2Vu dDogMTEgTWFyY2gsIDIwMTMgMjoyMSBBTQ0KPiBUbzogUm9uaSBFdmVuOyAnTWFyeSBCYXJuZXMn OyAnQ0xVRScNCj4gU3ViamVjdDogUkU6IFtjbHVlXSBDTFVFIERlc2lnbiBUZWFtIG1lZXRpbmcg b24gZm9yIHRvZGF5IC0gTWFyY2ggNHRoDQo+IA0KPiBIaSBSb25pLA0KPiANCj4gSSBoYWQgYSBs b29rIGF0IHlvdXIgZHJhZnQsIGFuZCBJIGxpa2UgaXQuIEkgdGhpbmsgaXQgYWxpZ25lZCB3ZWxs IHdpdGgNCj4gZHJhZnQtamVubmluZ3MtcnRjd2ViLXBsYW4tMDEsIGFuZCBJIGFncmVlIHdpdGgg eW91ciByZWNvbW1lbmRhdGlvbiBpbiA2LjINCj4gZm9yICBvbmUgb3IgbXVsdGlwbGUgUlRQIHN0 cmVhbXMgYXMgd2VsbCBhcyB5b3VyIGFzc2Vzc21lbnQgYXQgdGhlIGVuZCBvZg0KPiBzZWN0aW9u IDMgdGhhdCBuZWVkaW5nIHRvIGNvbnZleSBhbGwgU1NSQ3MgaW4gU0RQIHdpbGwgbm90IHNjYWxl IHdlbGwgZm9yDQo+IGxhcmdlIGNvbmZlcmVuY2VzLg0KPiANCj4gQ2hlZXJzLA0KPiBDaGFybGVz DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogY2x1ZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4g PiBPZiBSb25pIEV2ZW4NCj4gPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMDcsIDIwMTMgMTI6NDMg QU0NCj4gPiBUbzogJ01hcnkgQmFybmVzJzsgJ0NMVUUnDQo+ID4gU3ViamVjdDogUmU6IFtjbHVl XSBDTFVFIERlc2lnbiBUZWFtIG1lZXRpbmcgb24gZm9yIHRvZGF5IC0gTWFyY2ggNHRoDQo+ID4N Cj4gPiBIaSwNCj4gPiBJIGFtIHNvcnJ5IEkgbWlzc2VkIHRoZSBtZWV0aW5nLg0KPiA+IE9uIHRo ZSBTRFAgc3ViamVjdA0KPiA+IEpvbmF0aGFuLCBRaW4gYW5kIEkgc3VibWl0dGVkIGEgZG9jdW1l bnQgdG8gTU1VU0lDDQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZXZlbi1t bXVzaWMtbXVsdGlwbGUtc3RyZWFtcy0wMiB0aGF0DQo+ID4gdHJpZXMgdG8gYWRkcmVzcyBhbHNv IHRoZSBDTFVFIGNvbmNlcm5zLg0KPiA+IEl0IHdpbGwgYWxzbyBiZSBkaXNjdXNzZWQgaW4gdGhl IE1NVVNJQyBzZXNzaW9uIGFzIHdlbGwgYXMgdGhlIG9uZSB5b3UNCj4gPiBtZW50aW9uZWQgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWplbm5pbmdzLXJ0Y3dlYi1wbGFuLTAxDQo+ ID4gVGhpcyB0b3BpYyB3YXMgZGlzY3Vzc2VkIGluIHRoZSBNTVVTSUMgaW50ZXJpbSBtZWV0aW5n IGFuZCBpdCBpcw0KPiA+IGltcG9ydGFudCB0aGF0IHRoZSBDTFVFIGlucHV0IHNob3VsZCBiZSBh ZGRyZXNzZWQsIHBsZWFzZSB0cnkgdG8NCj4gPiBhdHRlbmQgYWxzbyB0aGUgTU1VU0lDIHNlc3Np b25zIChUdWVzZGF5IGFuZCBGcmlkYXkgKGZvbGxvd2luZw0KPiA+IEFWVGV4dCkgUm9uaQ0KPiA+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBjbHVlLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiA+IE9m IE1hcnkgQmFybmVzDQo+ID4gU2VudDogMDcgTWFyY2gsIDIwMTMgMjoxNyBBTQ0KPiA+IFRvOiBD TFVFDQo+ID4gU3ViamVjdDogUmU6IFtjbHVlXSBDTFVFIERlc2lnbiBUZWFtIG1lZXRpbmcgb24g Zm9yIHRvZGF5IC0gTWFyY2ggNHRoDQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBIZXJlIGlz IGEgc3VtbWFyeSBvZiBNb25kYXkncyBtZWV0aW5nLg0KPiA+DQo+ID4gQXR0ZW5kZWVzOiBNYXJ5 IEJhcm5lcywgTWFyayBEdWNrd29ydGgsIFJvYiBIYW5zZW4sIFBhdWwgS3l6aXZhdCwNCj4gPiBT aW1vbiBQaWV0cm8tUm9tYW5vDQo+ID4NCj4gPiBOb3RlczoNCj4gPiAtLS0tLS0tLS0NCj4gPiBU aGUgb2JqZWN0aXZlIG9mIHRoZSBtZWV0aW5nIHdhcyB0byByZXZpZXcgdGhlIHBsYW5zIGFuZCBh cmVhcyBvZg0KPiA+IGZvY3VzIGZvciBJRVRGLTg2Lg0KPiA+DQo+ID4gRnJhbWV3b3JrOg0KPiA+ IC0gd2l0aCByZWdhcmRzIHRvIFN0ZXBoYW4ncyBwb3J0aW9uIG9uIHRoZSBhZ2VuZGEsIHRoZSBl eHBlY3RhdGlvbiB3YXMNCj4gPiB0byBnZXQgYW4gdXBkYXRlIG9uIHRoZSByZXdvcmsgYW5kIHdh eSBmb3J3YXJkLg0KPiA+DQo+ID4gLSB3ZSBkaXNjdXNzZWQgdGhlIGluY29ycG9yYXRpb24gb2Yg Q2hyaXN0aWFuJ3Mgc3VnZ2VzdGlvbnMgKHBlciB0aGUNCj4gPiBkaXNjdXNzaW9uIG9mIGRyYWZ0 ICApIGludG8gdGhlIGZyYW1ld29yay4gIEFjdGlvbjogTWFyayB0byByZXZpZXcgYW5kDQo+ID4g ZGV0ZXJtaW5lIGlmL3doYXQgY2hhbmdlcyBhcmUgcmVxdWlyZWQgZm9yIHRoZSBmcmFtZXdvcmsN Cj4gPg0KPiA+IC0gTWFyayBub3RlZCB0aGF0IHRoZXJlIGFyZSBzb21lIGlzc3VlcyBpbiB0aGUg dHJhY2tlciB0aGF0IHNob3VsZCBiZQ0KPiA+IGNsb3NlZC4gQWN0aW9uOiBjaGFpcnMgcmV2aWV3 IGVtYWlscyBhbmQgY2xvc2UgcmVsYXRlZCBpc3N1ZXMNCj4gPg0KPiA+IC0gU2ltdWx0YW5lb3Vz IHNldHM6IGl0IGFwcGVhcnMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxpc3QgaXMgY29udmVyZ2lu Zy4NCj4gPiBNYXJrOiByZXZpZXcgYW5kIGRldGVybWluZSBmcmFtZXdvcmsgaW1wYWN0cy4NCj4g Pg0KPiA+IC0gUGF1bCBub3RlZCB0aGF0IFN0ZXBoYW4gaGFkIHNlbnQgYW4gZW1haWwgb24gRlcg aXNzdWVzLCBtb3N0IG9mDQo+ID4gd2hpY2ggcmVhbGx5IG5lZWQgdG8gYmUgcmVzb2x2ZWQgaW4g c29sdXRpb24gZG9jdW1lbnRzDQo+ID4NCj4gPiBTaWduYWxpbmcvc29sdXRpb246DQo+ID4gLSBO b3RlIHRoYXQgSm9uYXRoYW4gaGFzIHByb2R1Y2VkIGEgZHJhZnQgd2hpY2ggd2FzIGEgcmVzdWx0 IG9mIHRoZQ0KPiA+IGFjdGlvbiBpdGVtIGZyb20gSUVURi04NSBmb3IgdGhlIFJUQ1dFQi9DTFVF IGZvbGtzIHRvIHdvcmsgdG9nZXRoZXINCj4gPiBmb3IgYSBtb2RlbCBmb3INCj4gPiBSVFA6DQo+ ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1sZW5ub3gtcmFpYXJlYS1ydHAtZ3JvdXBp bmctdGF4b25vbXktMDAudA0KPiA+IHh0DQo+ID4NCj4gPiAtIEluIHRlcm1zIG9mIHRoZSBTaWdu YWxpbmcgcG9ydGlvbiBvZiB0aGUgYWdlbmRhIG9uIFR1ZXNkYXksIFBhdWwNCj4gPiB3aWxsIHBy b3ZpZGUgYW4gb3ZlcnZpZXcvdXBkYXRlIG9uIHRoZSBjdXJyZW50IHNpZ25hbGluZyBzb2x1dGlv bg0KPiBkb2N1bWVudC4NCj4gPiBUaGF0DQo+ID4gd2lsbCBsZWFkIGludG8gUm9iJ3MgZHJhZnQg c3BlY2lmaWNhbGx5IGFuYWx5emluZyBTRFAgdXNhZ2UuDQo+ID4NCj4gPiBBbHNvLCBmb2xrcyBz aG91bGQgcmVhZCB0aGlzIGRvY3VtZW50IHdoaWNoIGlkZW50aWZpZXMgcmVxdWlyZW1lbnRzDQo+ ID4gc29tZSBvZiB3aGljaCBhcmUgYXBwbGljYWJsZSB0byBDTFVFOg0KPiA+IGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWplbm5pbmdzLXJ0Y3dlYi1wbGFuLTAxDQo+ID4NCj4gPiBJ dCBpcyBvbiB0aGUgTU1VU0lDIFdHIGFnZW5kYSBmb3IgZGlzY3Vzc2lvbiBvbiBGcmlkYXk6DQo+ ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzg2L2FnZW5kYS9tbXVzaWMv DQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IE1hcnkuDQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+IGNs dWVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ns dWUNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gY2x1ZSBtYWlsaW5nIGxpc3QNCj4gPiBjbHVlQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= From rlb@ipv.sx Tue Mar 12 05: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 B5E0F21F86F7 for ; Tue, 12 Mar 2013 05:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 JHC8o6FB9MxR for ; Tue, 12 Mar 2013 05:25:13 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id EE4A521F8706 for ; Tue, 12 Mar 2013 05:25:01 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so4422507obc.13 for ; Tue, 12 Mar 2013 05:25:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Cd5twi/fgyOsyjB2dOAYaotA30XvDHWToRwxiLVYths=; b=QTUEL+9CAlDlD88lHaRmG8P0KE7JWJqT6zDX5Q82cn0dN/8CwdE4V0YNoZWM0lMg4M ZapX0xhATNkAkIO9oAIg2fucVcydUZ0mhvo9bQYL4XHEwxnEcccz4PTPv5dnkqy6INJA zJf3paaVekI447b7Xi8pX/G63jlIl9ii4ku3G7wSjb+FgwM5UXV8GjcwHlUBS2KXPOQj UXHLiFdfwelr08BY52MIYSDsgubmWcoJAEV5q2exdJo3EgzL/Np2bo3qoRygH3yxRy9S V7Q/JUYJ6b8vFBsOlEUrRZOwoUMdPhdrh3KEsH96jrR4A+x0/RFD935v7casaS1Xqk7a +sBg== MIME-Version: 1.0 X-Received: by 10.60.171.50 with SMTP id ar18mr11518376oec.24.1363091101421; Tue, 12 Mar 2013 05:25:01 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 05:25:01 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:b46a:6672:197f:e937] In-Reply-To: <51395C0F.2010201@nteczone.com> References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> <5138F39E.5060204@alum.mit.edu> <51395C0F.2010201@nteczone.com> Date: Tue, 12 Mar 2013 08:25:01 -0400 Message-ID: From: Richard Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=bcaec550af3ae5a38304d7b960df X-Gm-Message-State: ALoCoQlx9oY1/MrLKjJmbWvxmbd8R4frHmM7dZ1B4GnC+TbkUSiCPol0dDcxMB6ddavxJY+axXM7 Cc: clue@ietf.org Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 12 Mar 2013 12:25:15 -0000 --bcaec550af3ae5a38304d7b960df Content-Type: text/plain; charset=ISO-8859-1 I think this is a very useful taxonomy, and it seems like this group should focus on (1), at least initially. CLUE is about providing metadata on how a set of media streams relate to one another, so we should aspire to clean layering here. The CLUE protocol (1) should be mostly independent of SDP, as suggested by the last presentation yesterday. For example, ISTM that one very positive outcome here would be if it were possible for me to write an RTCWEB web app for telepresence, where the browser hands me a collection of media streams and a data channel, then I use CLUE over the data channel to figure out how to render those streams (and tell the far side about my streams). --Richard On Thu, Mar 7, 2013 at 10:33 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello, > > I think part of the problem may be that when people talk about "CLUE" they > actually mean different things. > > For me there's two aspects: 1) CLUE as a signalling protocol, and 2) how > to use CLUE in a SIP network. > > For 1) I can't see any need to incorporate SDP into the CLUE signalling. > For 2) SDP will be required in SIP networks to establish the CLUE data > channel. SDP will also be required to establish the media. > > It would be good for people to clarify what they mean when they are > talking about SDP. > > I personally think the RTCWEB work is a distraction and likewise the > RTPMUX work for the CLUE signalling protocol. RTPMUX is important for the > establishment of media. > > Regards, Christian > > > On 8/03/2013 7:07 AM, Paul Kyzivat wrote: > >> (as individual) >> >> Perhaps we should talk in rtcweb about what we are doing in clue, and >> suggest that some of the understanding of what the multiple streams *mean* >> in rtcweb should be left as application-specific. >> >> Thanks, >> Paul >> >> On 3/8/13 3:48 AM, Mary Barnes wrote: >> >>> On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg >>> > >>> wrote: >>> >>>> >>>> Hi, >>>> >>>> I agree with Paul. >>>> >>>> My personal starting point is still that the CLUE signalling should be >>>> used for the telepresence application related stuff, like spatial >>>> relationship etc. >>>> >>>> I also don't think that the RTCWEB outcome affect us, as far as our >>>> mechanism is concerned. However, if RTCWEB loses interest in pushing for >>>> SDP and/or RTP extensions that we also are interested in, WE may have to >>>> become more active in that work. >>>> >>> [MB] >>> I wasn't suggesting that their decision as to the >>> mechanism would directly impact CLUE. I'm suggesting that some of the >>> challenges they are having are due to the fact that they are trying to >>> use SDP for something that it really wasn't designed or envisioned to >>> be used for. I do believe that some of the issues with SDP that they >>> are encountering that is making folks rethink the RTCWEB decision are >>> not unlike those that CLUE may have to deal with. I strongly believe >>> that decoupling the CLUE application from SDP as much as possible is a >>> better path than trying to put so much into SDP (which is a *similar* >>> discussion as is happening in RTCWEB in terms of decoupling the API >>> from SDP). I understand that we are using SIP for session setup, so >>> of course, we will need to use SDP O/A and thus we can't totally >>> decouple. As we have been discussing for well over a year, the >>> challenge is how much of the CLUE application information should be >>> carried in SDP versus a CLUE specific protocol. >>> >>> >>> We should already be more active in the work and not >>> expect that we would just use what RTCWEB needs. CLUE requirements >>> should be considered equal to those of RTCWEB. I think we also need >>> to be very thoughtful as to how we make our decisions so we don't end >>> up a year from now with folks questioning the path we chose. >>> >>> >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> ______________________________**__________ >>>> From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul >>>> Kyzivat [pkyzivat@alum.mit.edu] >>>> Sent: Thursday, 07 March 2013 9:12 PM >>>> To: Mary Barnes >>>> Cc: CLUE >>>> Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model >>>> >>>> I don't fully agree with Mary on this. >>>> >>>> First, I don't think that discussion in RTCWEB has much bearing on CLUE. >>>> RTCWEB uses a non-sip signaling model. And it doesn't even call for use >>>> of SDP in signaling. Rather it only uses SDP for communication between >>>> the javascript and the browser it runs in. It doesn't require that the >>>> SDP constructed in one broswer be identical to that seen in the browser >>>> at the other end. SDP has long been a poor choice for the purpose we use >>>> it, but we have legacy reasons to continue and efforts to move to SDPng >>>> failed. It is extremely poor as an abstract conceptual representation >>>> for an API. So IMO it makes sense to think hard about whether to use it >>>> in RTCWEB. The argument there is not what to put in SDP and what to do >>>> another way, it is about whether to use SDP or not. >>>> >>>> But CLUE is mostly SIP-based. We are going to be using SDP. For us the >>>> question is how much to put in SDP and how much to put in the CLUE >>>> protocol. I don't think the rtcweb arguments are helpful about that. >>>> >>>> IMO we should use SDP for the things it does, and perhaps extend it a >>>> bit for things it *ought* to do, philosophically. SDP O/A is focused on >>>> two ends negotiating based on what each is prepared to receive. >>>> Sometimes it talks about what is to be sent, but it isn't so good about >>>> that. In the end the result of the negotiation defines characteristics >>>> of what *will* be sent. And that part is important to some middle boxes, >>>> so we should try hard not to break that. >>>> >>>> Clue is focused on presenting a menu of what *could* be *sent* and then >>>> selecting from that menu what should be sent, and how. It is pretty hard >>>> to work out what SDP is required until all that is known. So I prefer >>>> keeping the division that way - the SDP is only used to signal the >>>> details to support what will be sent, based on what was agreed in the >>>> clue signaling. >>>> >>>> In some cases this may lead to conflicts. For instance, SDP has the >>>> a=content attribute. In our clue data model and signaling we will have a >>>> much richer mechanism to describe similar characteristics. IMO we should >>>> not feel a need to exclusively use SDP for this. I don't know that we >>>> need to use it at all between clue-aware endpoints, though we ought to >>>> do as much as we can when talking to legacy endpoints. >>>> >>>> So in practice I will probably agree with Mary most of the time about >>>> what should be in SDP and what should not. >>>> >>>> I'll also observe that the less we depend on SDP the less trouble we >>>> will have making CLUE work in RTCWEB. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 3/8/13 2:08 AM, Mary Barnes wrote: >>>> >>>>> I really think CLUE folks need to read this thread and understand the >>>>> issues: >>>>> http://www.ietf.org/mail-**archive/web/rtcweb/current/**msg06612.html >>>>> >>>>> While we aren't defining an API, we are defining a application. I >>>>> think it's important to carefully consider the tradeoffs in terms of >>>>> how much is carried in SDP versus how much we can do with a CLUE >>>>> specific protocol. >>>>> >>>>> >>>>> I really, really think that the more we put in SDP, the less >>>>> extensibility we will have for the CLUE application - I think we >>>>> really, really need to carefully weigh the tradeoffs between tightly >>>>> coupling the CLUE application to SDP versus minimizing the >>>>> interactions and duplication of information. >>>>> >>>>> In one sense, this is a similar problem we faced with SIP >>>>> conferencing. We defined some basic extensions that worked just fine. >>>>> But, it would have been a bear to add all the additional functionality >>>>> for complex scenarios to SIP. Instead, we defined XCON, which >>>>> decouples the conferencing application from the session >>>>> setup/signaling protocol. XCON is highly extensible and flexible and >>>>> provides a rich set of application functionality. I believe we want >>>>> to same with CLUE a >>>>> >>>>> >>>>> >>>>> Mary. >>>>> >>>>> >>>> ______________________________**_________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/clue >>>> >>> >>> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --bcaec550af3ae5a38304d7b960df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <hat type=3D"individual"/>

I think this = is a very useful taxonomy, and it seems like this group should focus on (1)= , at least initially. =A0CLUE is about providing metadata on how a set of m= edia streams relate to one another, so we should aspire to clean layering h= ere. =A0The CLUE protocol (1) should be mostly independent of SDP, as sugge= sted by the last presentation yesterday.

For example, ISTM that one very positive outcome here w= ould be if it were possible for me to write an RTCWEB web app for teleprese= nce, where the browser hands me a collection of media streams and a data ch= annel, then I use CLUE over the data channel to figure out how to render th= ose streams (and tell the far side about my streams). =A0

--Richard


= On Thu, Mar 7, 2013 at 10:33 PM, Christian Groves <Christian.G= roves@nteczone.com> wrote:
Hello,

I think part of the problem may be that when people talk about "CLUE&q= uot; they actually mean different things.

For me there's two aspects: 1) CLUE as a signalling protocol, and 2) ho= w to use CLUE in a SIP network.

For 1) I can't see any need to incorporate SDP into the CLUE signalling= .
For 2) SDP will be required in SIP networks to establish the CLUE data chan= nel. SDP will also be required to establish the media.

It would be good for people to clarify what they mean when they are talking= about SDP.

I personally think the RTCWEB work is a distraction and likewise the RTPMUX= work for the CLUE signalling protocol. RTPMUX is important for the establi= shment of media.

Regards, Christian


On 8/03/2013 7:07 AM, Paul Kyzivat wrote:
(as individual)

Perhaps we should talk in rtcweb about what we are doing in clue, and sugge= st that some of the understanding of what the multiple streams *mean* in rt= cweb should be left as application-specific.

=A0 =A0 Thanks,
=A0 =A0 Paul

On 3/8/13 3:48 AM, Mary Barnes wrote:
On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg
<chr= ister.holmberg@ericsson.com> wrote:

Hi,

I agree with Paul.

My personal starting point is still that the CLUE signalling should be used= for the telepresence application related stuff, like spatial relationship = etc.

I also don't think that the RTCWEB outcome affect us, as far as our mec= hanism is concerned. However, if RTCWEB loses interest in pushing for SDP a= nd/or RTP extensions that we also are interested in, WE may have to become = more active in that work.
[MB]
<as individual> I wasn't suggesting that their decision as to the=
mechanism would directly impact CLUE. =A0I'm suggesting that some of th= e
challenges they are having are due to the fact that they are trying to
use SDP for something that it really wasn't designed or envisioned to be used for. =A0 I do believe that some of the issues with SDP that they are encountering that is making folks rethink the RTCWEB decision are
not unlike those that CLUE may have to deal with. =A0I strongly believe
that decoupling the CLUE application from SDP as much as possible is a
better path than trying to put so much into SDP (which is a *similar*
discussion as is happening in RTCWEB in terms of decoupling the API
from SDP). =A0 I understand that we are using SIP for session setup, so
of course, we will need to use SDP O/A and thus we can't totally
decouple. =A0As we have been discussing for well over a year, the
challenge is how much of the CLUE application information should be
carried in SDP versus a CLUE specific protocol.
</individual>

<as chair> =A0We should already be more active in the work and not expect that we would just use what RTCWEB needs. CLUE requirements
should be considered equal to those of RTCWEB. =A0 I think we also need
to be very thoughtful as to how we make our decisions so we don't end up a year from now with folks questioning the path we chose.
</chair>


Regards,

Christer


________________________________________
From: clue-bounc= es@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu]
Sent: Thursday, 07 March 2013 9:12 PM
To: Mary Barnes
Cc: CLUE
Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model

I don't fully agree with Mary on this.

First, I don't think that discussion in RTCWEB has much bearing on CLUE= .
RTCWEB uses a non-sip signaling model. And it doesn't even call for use=
of SDP in signaling. Rather it only uses SDP for communication between
the javascript and the browser it runs in. It doesn't require that the<= br> SDP constructed in one broswer be identical to that seen in the browser
at the other end. SDP has long been a poor choice for the purpose we use it, but we have legacy reasons to continue and efforts to move to SDPng
failed. It is extremely poor as an abstract conceptual representation
for an API. So IMO it makes sense to think hard about whether to use it
in RTCWEB. The argument there is not what to put in SDP and what to do
another way, it is about whether to use SDP or not.

But CLUE is mostly SIP-based. We are going to be using SDP. For us the
question is how much to put in SDP and how much to put in the CLUE
protocol. I don't think the rtcweb arguments are helpful about that.
IMO we should use SDP for the things it does, and perhaps extend it a
bit for things it *ought* to do, philosophically. SDP O/A is focused on
two ends negotiating based on what each is prepared to receive.
Sometimes it talks about what is to be sent, but it isn't so good about=
that. In the end the result of the negotiation defines characteristics
of what *will* be sent. And that part is important to some middle boxes, so we should try hard not to break that.

Clue is focused on presenting a menu of what *could* be *sent* and then
selecting from that menu what should be sent, and how. It is pretty hard to work out what SDP is required until all that is known. So I prefer
keeping the division that way - the SDP is only used to signal the
details to support what will be sent, based on what was agreed in the
clue signaling.

In some cases this may lead to conflicts. For instance, SDP has the
a=3Dcontent attribute. In our clue data model and signaling we will have a<= br> much richer mechanism to describe similar characteristics. IMO we should not feel a need to exclusively use SDP for this. I don't know that we need to use it at all between clue-aware endpoints, though we ought to
do as much as we can when talking to legacy endpoints.

So in practice I will probably agree with Mary most of the time about
what should be in SDP and what should not.

I'll also observe that the less we depend on SDP the less trouble we will have making CLUE work in RTCWEB.

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

On 3/8/13 2:08 AM, Mary Barnes wrote:
I really think CLUE folks need to read this thread and understand the issue= s:
http://www.ietf.org/mail-archive/web/rtcweb/cur= rent/msg06612.html

While we aren't defining an API, we are defining a application. =A0I think it's important to carefully consider the tradeoffs in terms of how much is carried in SDP versus how much we can do with a CLUE
specific protocol.

<as an individual>
I really, really think that the more we put in SDP, the less
extensibility we will have for the CLUE application - I think we
really, really need to carefully weigh the tradeoffs between tightly
coupling the CLUE application to SDP versus minimizing the
interactions and duplication of information.

In one sense, this is a similar problem we faced with SIP
conferencing. =A0We defined some basic extensions that worked just fine. But, it would have been a bear to add all the additional functionality
for complex scenarios to SIP. =A0Instead, we defined XCON, which
decouples the conferencing application from the session
setup/signaling protocol. =A0XCON is highly extensible and flexible and
provides a rich set of application functionality. =A0I believe we want
to same with CLUE a

</individual>

Mary.


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


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


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

--bcaec550af3ae5a38304d7b960df-- From pkyzivat@alum.mit.edu Tue Mar 12 05:29:44 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 7BC5321F8A2A for ; Tue, 12 Mar 2013 05:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.008 X-Spam-Level: X-Spam-Status: No, score=-0.008 tagged_above=-999 required=5 tests=[AWL=0.429, 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 evMLyzaPPFZs for ; Tue, 12 Mar 2013 05:29:44 -0700 (PDT) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:80]) by ietfa.amsl.com (Postfix) with ESMTP id 0448821F858C for ; Tue, 12 Mar 2013 05:29:43 -0700 (PDT) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta08.emeryville.ca.mail.comcast.net with comcast id AcUv1l0010lTkoCA8cVeQ1; Tue, 12 Mar 2013 12:29:38 +0000 Received: from dhcp-11c0.meeting.ietf.org ([IPv6:2001:df8:0:16:54d7:7457:e848:f3a]) by omta04.emeryville.ca.mail.comcast.net with comcast id AcVd1l00J4W91r58QcVd6W; Tue, 12 Mar 2013 12:29:38 +0000 Message-ID: <513F1FB2.2070307@alum.mit.edu> Date: Tue, 12 Mar 2013 20:29:38 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> <5138F39E.5060204@alum.mit.edu> <51395C0F.2010201@nteczone.com> <513A0B38.1090309@alum.mit.edu> <513E5684.5010404@nteczone.com> In-Reply-To: <513E5684.5010404@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=1363091378; bh=SfQXBp2lSVbhY6eu4tJ2BtiQ8HyDLvW1FLPIRJQK9mQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qv7A5z8oqgCY1rPSYtPinPBqmkrPBtQ4Sb2zZPh5jsglRYQRs8Q1eZUF/QH3LK4l9 TmeQ/h2IODhOb9rZUEVOR6Uu9+59Zm/v8KWDm6Jv6CcwLP0V6HmMwHeaelr3rtJ54e kfbfbY0VgMtIH82kaebs0HqpZAvmj/n3VIzcXFpRfp6dhBXvdOwiV5f719/wGPVeDm jkcWL1uQbzEtMtS/1V8A/MNUH3SsbKmAwtNP1AggQYdcNWchHCkp9CvMYAVx/iTUfL aBWgnyYlAvQRoItZTU6qsOFCmlSfIaAJ9HTdX+69TfGoCBe8iiE7twBG96xEpMvgtf sDo3PJjy91kcg== Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 12 Mar 2013 12:29:44 -0000 On 3/12/13 6:11 AM, Christian Groves wrote: > Hello Paul, > > Please see my response below. > > Regards, Christian > > On 9/03/2013 3:00 AM, Paul Kyzivat wrote: >> Hi Christian, >> >> On 3/8/13 11:33 AM, Christian Groves wrote: >>> Hello, >>> >>> I think part of the problem may be that when people talk about "CLUE" >>> they actually mean different things. >>> >>> For me there's two aspects: 1) CLUE as a signalling protocol, and 2) how >>> to use CLUE in a SIP network. >> >> OK. I'll agree with you that these are conceptually different things, >> and that we we have not been keeping them distinct. I think one reason >> is that we aren't entirely sure where to draw the line between them. >> >>> For 1) I can't see any need to incorporate SDP into the CLUE signalling. >> >> AFAIK nobody is proposing the "incorporate SDP into the CLUE signaling". >> >> But we are considering omitting some things from the CLUE signaling >> because they will instead be signaled in SDP. And also, there is a >> need to couple the CLUE signaling to the SDP - at least to correlate a >> capture-encoding in a Configure to an m-line in the SDP. (And maybe >> some correlation between the Advertisement and the SDP as well.) > [CNG] Omitting? IS there something in the framework that is thought can > be omitted? There have been some proposals that information about encodings might be entirely in SDP. There has been no decision to go that way, but it is a possibility. [snip] >>> and likewise the >>> RTPMUX work for the CLUE signalling protocol. RTPMUX is important for >>> the establishment of media. >> >> I don't understand your point here. You are saying the RTPMUX is >> important but its a distraction??? > [CNG] Yes. The CLUE protocol can/should happily exist without the need > for RTPMUX. Of course as the framework points out there are real world > limitation on ports. Endpoints implementing CLUE may also want to > implement RTPMuxing. We should be able to finish the CLUE work even if > RTPmux work is ongoing. OK, good point. I agree this is possible. Thanks, Paul From eckelcu@cisco.com Tue Mar 12 11:51: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 BEE5411E8135 for ; Tue, 12 Mar 2013 11:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[AWL=-2.271, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 zoyVDosBR6Cf for ; Tue, 12 Mar 2013 11:51:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4279111E812A for ; Tue, 12 Mar 2013 11:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8494; q=dns/txt; s=iport; t=1363114274; x=1364323874; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9/Bu0UQdOYq9Bg/h3GP4angQeiVUT03/MKBc9MQ9Jfw=; b=l7nFJqWvuFl/G/LwiBEnytDQr/kawr6NE2WrhmopsXstJ5IrcnQCTX6h Pb1D12fNXcCAJQH0r8dAUvJWIJMLVRSU3jK5qE937hN582D21QrwBzbrZ cEDXrmuqrfVmwtGrmZ8mr0pIULIOTozle5f1NSRvuimuayA20gsxRPc9W Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAAh4P1GtJXG9/2dsb2JhbAA5CogXvFNebRZ0gikBAQEEAQEBMTQGFwQCAQYCDgMEAQEFBh0FAgIfBgsUCQgCBAESCAESh2cDDwyUEJp9CII+hgoNiUQXgR+LJoEHBoEKFhASBoIjNmEDlHaCf4o+hRmDCoFzNQ X-IronPort-AV: E=Sophos;i="4.84,832,1355097600"; d="scan'208";a="186673253" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2013 18:51:13 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2CIpDo0018029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 18:51:13 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 13:51:12 -0500 From: "Charles Eckel (eckelcu)" To: Qin Wu , Roni Even , "'Mary Barnes'" , "'CLUE'" Thread-Topic: [clue] CLUE Design Team meeting on for today - March 4th Thread-Index: AQHOGPJ2c8pfmqoDBku99gZdNL/bqJiZxPqAgACNOwCABRsO0IAAma6A///HdNCAAoG7AIAAIqpA Date: Tue, 12 Mar 2013 18:51:11 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D2B39@xmb-aln-x08.cisco.com> References: <05d601ce1b0f$c4399310$4cacb930$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CBFAF@xmb-aln-x08.cisco.com> <009301ce1df2$853be830$8fb3b890$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CC1A7@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.254] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th 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, 12 Mar 2013 18:51:15 -0000 TXNpZCBpcyBhIG1lZGlhIHN0cmVhbSBJRCwgbm90IG5lY2Vzc2FyaWx5IGEgZGV2aWNlIElELg0K ZHJhZnQtaWV0Zi1tbXVzaWMtbXNpZC0wMCBkZWZpbmVzIGEgc2VtYW50aWMgZm9yIHVzYWdlIHdp dGggV2ViUlRDIGluIHdoaWNoIG1zaWQgaXMgYSBXZWJSVEMgbWVkaWEgc3RyZWFtLg0KT3RoZXIg c2VtYW50aWNzIG1heSBiZSBkZWZpbmVkIGJ5IGZ1dHVyZSBkcmFmdHMuDQoNCkNoZWVycywNCkNo YXJsZXMNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBRaW4gV3UgW21h aWx0bzpiaWxsLnd1QGh1YXdlaS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDEyLCAyMDEz IDc6NDYgQU0NCj4gVG86IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpOyBSb25pIEV2ZW47ICdNYXJ5 IEJhcm5lcyc7ICdDTFVFJw0KPiBTdWJqZWN0OiC08Li0OiBbY2x1ZV0gQ0xVRSBEZXNpZ24gVGVh bSBtZWV0aW5nIG9uIGZvciB0b2RheSAtIE1hcmNoIDR0aA0KPiANCj4gT25lIGNvbmZ1c2lvbiB3 aGVuIEkgcmVhZCBjdWxsZW4ncyBkcmFmdCBhYm91dCBNU0lEIHVzYWdlPyBJcyBNU0lEIHVzZWQg dG8NCj4gaWRlbnRpZnkgZWFjaCBtZWRpYSBzdHJlYW0gb3IgSXMgTVNJRCB1c2VkIHRvIGlkZW50 aWZ5IGVhY2ggZGV2aWNlDQo+IGlkZW50aWZpZXI/DQo+IEkgY2FuIHVuZGVyc3RhbmQgdGhlIGZv cm1lciBjYXNlLCBzZWVtcyBpdCBpcyBxdWl0ZSBzaW1pbGFyIHRvIG11bHRpLWNoYW5uZWwNCj4g YXVkaW8gY2FzZS4gQnV0IEkgYW0gbG9zdCB3aGVuIE1TSUQgaXMgcmVwdXJwb3NlZCBhcyBkZXZp Y2UgaWRlbnRpZmllci4NCj4gDQo+IFJlZ2FyZHMhDQo+IC1RaW4NCj4gLS0tLS3Tyrz+1K28/i0t LS0tDQo+ILeivP7IyzogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2Vz QGlldGYub3JnXSC0+rHtDQo+IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpDQo+ILeiy83KsbzkOiAy MDEzxOoz1MIxMMjVIDIyOjMxDQo+IMrVvP7IyzogUm9uaSBFdmVuOyAnTWFyeSBCYXJuZXMnOyAn Q0xVRScNCj4g1vfM4jogUmU6IFtjbHVlXSBDTFVFIERlc2lnbiBUZWFtIG1lZXRpbmcgb24gZm9y IHRvZGF5IC0gTWFyY2ggNHRoDQo+IA0KPiBZZXMsIEkgaGFkIGEgc2ltaWxhciB0aG91Z2h0LiBJ IHRoaW5rICgxKSBjb3VsZCBiZSBtb2RpZmllZCB0byBiZSBsaWtlICgzKSwNCj4gc2F5aW5nIHRo YXQgIiBpdCBNVVNUIHVzZSBzZXBhcmF0ZSBtLWJsb2NrcyBmb3IgZWFjaCB1bmxlc3MgZXhwbGlj aXRseQ0KPiBzaWduYWxlZCB0byBiZSBvdGhlcndpc2UgKHNlZSBTZWN0aW9uIDcuMikuDQo+IA0K PiBDaGVlcnMsDQo+IENoYXJsZXMNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiBGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb24uZXZlbi50bHZAZ21haWwuY29tXQ0KPiA+ IFNlbnQ6IFN1bmRheSwgTWFyY2ggMTAsIDIwMTMgODo1MSBQTQ0KPiA+IFRvOiBDaGFybGVzIEVj a2VsIChlY2tlbGN1KTsgJ01hcnkgQmFybmVzJzsgJ0NMVUUnDQo+ID4gU3ViamVjdDogUkU6IFtj bHVlXSBDTFVFIERlc2lnbiBUZWFtIG1lZXRpbmcgb24gZm9yIHRvZGF5IC0gTWFyY2ggNHRoDQo+ ID4NCj4gPiBDaGFybGVzLA0KPiA+IFdoZW4gcmVhZGluZyBDdWxsZW4ncyBkcmFmdCBJIGFsc28g dGhvdWdodCBzbyBidXQgaGFkIGEgcHJvYmxlbSB3aGVuDQo+ID4gcmVhZGluZw0KPiA+IHRoZSBm aXJzdCBidWxsZXQgaW4gc2VjdGlvbiA3Lg0KPiA+IFRoZXJlIGFyZSBzb21lIG90aGVyIG1pbm9y IGlzc3VlcyBsaWtlIHRoZSBTU1JDIHVzYWdlIGluIHRoZSBkaWZmZXJlbnQNCj4gPiB0b3BvbG9n aWVzLg0KPiA+IFJvbmkNCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogQ2hhcmxlcyBFY2tlbCAoZWNrZWxjdSkgW21haWx0bzplY2tlbGN1QGNpc2NvLmNvbV0N Cj4gPiBTZW50OiAxMSBNYXJjaCwgMjAxMyAyOjIxIEFNDQo+ID4gVG86IFJvbmkgRXZlbjsgJ01h cnkgQmFybmVzJzsgJ0NMVUUnDQo+ID4gU3ViamVjdDogUkU6IFtjbHVlXSBDTFVFIERlc2lnbiBU ZWFtIG1lZXRpbmcgb24gZm9yIHRvZGF5IC0gTWFyY2ggNHRoDQo+ID4NCj4gPiBIaSBSb25pLA0K PiA+DQo+ID4gSSBoYWQgYSBsb29rIGF0IHlvdXIgZHJhZnQsIGFuZCBJIGxpa2UgaXQuIEkgdGhp bmsgaXQgYWxpZ25lZCB3ZWxsIHdpdGgNCj4gPiBkcmFmdC1qZW5uaW5ncy1ydGN3ZWItcGxhbi0w MSwgYW5kIEkgYWdyZWUgd2l0aCB5b3VyIHJlY29tbWVuZGF0aW9uIGluDQo+IDYuMg0KPiA+IGZv ciAgb25lIG9yIG11bHRpcGxlIFJUUCBzdHJlYW1zIGFzIHdlbGwgYXMgeW91ciBhc3Nlc3NtZW50 IGF0IHRoZSBlbmQgb2YNCj4gPiBzZWN0aW9uIDMgdGhhdCBuZWVkaW5nIHRvIGNvbnZleSBhbGwg U1NSQ3MgaW4gU0RQIHdpbGwgbm90IHNjYWxlIHdlbGwgZm9yDQo+ID4gbGFyZ2UgY29uZmVyZW5j ZXMuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gQ2hhcmxlcw0KPiA+DQo+ID4gPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPiA+IE9mIFJvbmkgRXZlbg0K PiA+ID4gU2VudDogVGh1cnNkYXksIE1hcmNoIDA3LCAyMDEzIDEyOjQzIEFNDQo+ID4gPiBUbzog J01hcnkgQmFybmVzJzsgJ0NMVUUnDQo+ID4gPiBTdWJqZWN0OiBSZTogW2NsdWVdIENMVUUgRGVz aWduIFRlYW0gbWVldGluZyBvbiBmb3IgdG9kYXkgLSBNYXJjaCA0dGgNCj4gPiA+DQo+ID4gPiBI aSwNCj4gPiA+IEkgYW0gc29ycnkgSSBtaXNzZWQgdGhlIG1lZXRpbmcuDQo+ID4gPiBPbiB0aGUg U0RQIHN1YmplY3QNCj4gPiA+IEpvbmF0aGFuLCBRaW4gYW5kIEkgc3VibWl0dGVkIGEgZG9jdW1l bnQgdG8gTU1VU0lDDQo+ID4gPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ldmVu LW1tdXNpYy1tdWx0aXBsZS1zdHJlYW1zLTAyIHRoYXQNCj4gPiA+IHRyaWVzIHRvIGFkZHJlc3Mg YWxzbyB0aGUgQ0xVRSBjb25jZXJucy4NCj4gPiA+IEl0IHdpbGwgYWxzbyBiZSBkaXNjdXNzZWQg aW4gdGhlIE1NVVNJQyBzZXNzaW9uIGFzIHdlbGwgYXMgdGhlIG9uZSB5b3UNCj4gPiA+IG1lbnRp b25lZCAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamVubmluZ3MtcnRjd2ViLXBs YW4tMDENCj4gPiA+IFRoaXMgdG9waWMgd2FzIGRpc2N1c3NlZCBpbiB0aGUgTU1VU0lDIGludGVy aW0gbWVldGluZyBhbmQgaXQgaXMNCj4gPiA+IGltcG9ydGFudCB0aGF0IHRoZSBDTFVFIGlucHV0 IHNob3VsZCBiZSBhZGRyZXNzZWQsIHBsZWFzZSB0cnkgdG8NCj4gPiA+IGF0dGVuZCBhbHNvIHRo ZSBNTVVTSUMgc2Vzc2lvbnMgKFR1ZXNkYXkgYW5kIEZyaWRheSAoZm9sbG93aW5nDQo+ID4gPiBB VlRleHQpIFJvbmkNCj4gPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2x1ZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYNCj4gPiA+IE9mIE1hcnkgQmFybmVzDQo+ID4gPiBTZW50OiAwNyBNYXJj aCwgMjAxMyAyOjE3IEFNDQo+ID4gPiBUbzogQ0xVRQ0KPiA+ID4gU3ViamVjdDogUmU6IFtjbHVl XSBDTFVFIERlc2lnbiBUZWFtIG1lZXRpbmcgb24gZm9yIHRvZGF5IC0gTWFyY2ggNHRoDQo+ID4g Pg0KPiA+ID4gSGkgYWxsLA0KPiA+ID4NCj4gPiA+IEhlcmUgaXMgYSBzdW1tYXJ5IG9mIE1vbmRh eSdzIG1lZXRpbmcuDQo+ID4gPg0KPiA+ID4gQXR0ZW5kZWVzOiBNYXJ5IEJhcm5lcywgTWFyayBE dWNrd29ydGgsIFJvYiBIYW5zZW4sIFBhdWwgS3l6aXZhdCwNCj4gPiA+IFNpbW9uIFBpZXRyby1S b21hbm8NCj4gPiA+DQo+ID4gPiBOb3RlczoNCj4gPiA+IC0tLS0tLS0tLQ0KPiA+ID4gVGhlIG9i amVjdGl2ZSBvZiB0aGUgbWVldGluZyB3YXMgdG8gcmV2aWV3IHRoZSBwbGFucyBhbmQgYXJlYXMg b2YNCj4gPiA+IGZvY3VzIGZvciBJRVRGLTg2Lg0KPiA+ID4NCj4gPiA+IEZyYW1ld29yazoNCj4g PiA+IC0gd2l0aCByZWdhcmRzIHRvIFN0ZXBoYW4ncyBwb3J0aW9uIG9uIHRoZSBhZ2VuZGEsIHRo ZSBleHBlY3RhdGlvbiB3YXMNCj4gPiA+IHRvIGdldCBhbiB1cGRhdGUgb24gdGhlIHJld29yayBh bmQgd2F5IGZvcndhcmQuDQo+ID4gPg0KPiA+ID4gLSB3ZSBkaXNjdXNzZWQgdGhlIGluY29ycG9y YXRpb24gb2YgQ2hyaXN0aWFuJ3Mgc3VnZ2VzdGlvbnMgKHBlciB0aGUNCj4gPiA+IGRpc2N1c3Np b24gb2YgZHJhZnQgICkgaW50byB0aGUgZnJhbWV3b3JrLiAgQWN0aW9uOiBNYXJrIHRvIHJldmll dyBhbmQNCj4gPiA+IGRldGVybWluZSBpZi93aGF0IGNoYW5nZXMgYXJlIHJlcXVpcmVkIGZvciB0 aGUgZnJhbWV3b3JrDQo+ID4gPg0KPiA+ID4gLSBNYXJrIG5vdGVkIHRoYXQgdGhlcmUgYXJlIHNv bWUgaXNzdWVzIGluIHRoZSB0cmFja2VyIHRoYXQgc2hvdWxkIGJlDQo+ID4gPiBjbG9zZWQuIEFj dGlvbjogY2hhaXJzIHJldmlldyBlbWFpbHMgYW5kIGNsb3NlIHJlbGF0ZWQgaXNzdWVzDQo+ID4g Pg0KPiA+ID4gLSBTaW11bHRhbmVvdXMgc2V0czogaXQgYXBwZWFycyB0aGUgZGlzY3Vzc2lvbiBv biB0aGUgbGlzdCBpcyBjb252ZXJnaW5nLg0KPiA+ID4gTWFyazogcmV2aWV3IGFuZCBkZXRlcm1p bmUgZnJhbWV3b3JrIGltcGFjdHMuDQo+ID4gPg0KPiA+ID4gLSBQYXVsIG5vdGVkIHRoYXQgU3Rl cGhhbiBoYWQgc2VudCBhbiBlbWFpbCBvbiBGVyBpc3N1ZXMsIG1vc3Qgb2YNCj4gPiA+IHdoaWNo IHJlYWxseSBuZWVkIHRvIGJlIHJlc29sdmVkIGluIHNvbHV0aW9uIGRvY3VtZW50cw0KPiA+ID4N Cj4gPiA+IFNpZ25hbGluZy9zb2x1dGlvbjoNCj4gPiA+IC0gTm90ZSB0aGF0IEpvbmF0aGFuIGhh cyBwcm9kdWNlZCBhIGRyYWZ0IHdoaWNoIHdhcyBhIHJlc3VsdCBvZiB0aGUNCj4gPiA+IGFjdGlv biBpdGVtIGZyb20gSUVURi04NSBmb3IgdGhlIFJUQ1dFQi9DTFVFIGZvbGtzIHRvIHdvcmsgdG9n ZXRoZXINCj4gPiA+IGZvciBhIG1vZGVsIGZvcg0KPiA+ID4gUlRQOg0KPiA+ID4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1sZW5ub3gtcmFpYXJlYS1ydHAtZ3JvdXBpbmctdGF4b25vbXkt DQo+IDAwLnQNCj4gPiA+IHh0DQo+ID4gPg0KPiA+ID4gLSBJbiB0ZXJtcyBvZiB0aGUgU2lnbmFs aW5nIHBvcnRpb24gb2YgdGhlIGFnZW5kYSBvbiBUdWVzZGF5LCBQYXVsDQo+ID4gPiB3aWxsIHBy b3ZpZGUgYW4gb3ZlcnZpZXcvdXBkYXRlIG9uIHRoZSBjdXJyZW50IHNpZ25hbGluZyBzb2x1dGlv bg0KPiA+IGRvY3VtZW50Lg0KPiA+ID4gVGhhdA0KPiA+ID4gd2lsbCBsZWFkIGludG8gUm9iJ3Mg ZHJhZnQgc3BlY2lmaWNhbGx5IGFuYWx5emluZyBTRFAgdXNhZ2UuDQo+ID4gPg0KPiA+ID4gQWxz bywgZm9sa3Mgc2hvdWxkIHJlYWQgdGhpcyBkb2N1bWVudCB3aGljaCBpZGVudGlmaWVzIHJlcXVp cmVtZW50cw0KPiA+ID4gc29tZSBvZiB3aGljaCBhcmUgYXBwbGljYWJsZSB0byBDTFVFOg0KPiA+ ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamVubmluZ3MtcnRjd2ViLXBsYW4t MDENCj4gPiA+DQo+ID4gPiBJdCBpcyBvbiB0aGUgTU1VU0lDIFdHIGFnZW5kYSBmb3IgZGlzY3Vz c2lvbiBvbiBGcmlkYXk6DQo+ID4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRp bmcvODYvYWdlbmRhL21tdXNpYy8NCj4gPiA+DQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4gTWFyeS4N Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gPiBjbHVlIG1haWxpbmcgbGlzdA0KPiA+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo+ID4gPg0KPiA+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IGNsdWUgbWFp bGluZyBsaXN0DQo+ID4gPiBjbHVlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IGNsdWUgbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= From bill.wu@huawei.com Tue Mar 12 13:11: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 0937E11E8163 for ; Tue, 12 Mar 2013 13:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.198 X-Spam-Level: X-Spam-Status: No, score=0.198 tagged_above=-999 required=5 tests=[AWL=2.255, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 VFaHO29K6jXm for ; Tue, 12 Mar 2013 13:10:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 063DA11E810B for ; Tue, 12 Mar 2013 13:10:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APH61142; Tue, 12 Mar 2013 20:10:34 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Mar 2013 20:10:01 +0000 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Mar 2013 20:10:32 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.126]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Wed, 13 Mar 2013 04:10:27 +0800 From: Qin Wu To: "Charles Eckel (eckelcu)" , Roni Even , "'Mary Barnes'" , "'CLUE'" Thread-Topic: [clue] CLUE Design Team meeting on for today - March 4th Thread-Index: AQHOGPJxn0nTyiC3EUiCZPwHdqnDe5iY2kiAgACNOwCABb04AIAACEiAgAAb7ICAArJKMP//8eaAgACb5yA= Date: Tue, 12 Mar 2013 20:10:27 +0000 Message-ID: References: <05d601ce1b0f$c4399310$4cacb930$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CBFAF@xmb-aln-x08.cisco.com> <009301ce1df2$853be830$8fb3b890$@gmail.com> <92B7E61ADAC1BB4F941F943788C08828047CC1A7@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C08828047D2B39@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047D2B39@xmb-aln-x08.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.138] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [clue] CLUE Design Team meeting on for today - March 4th 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, 12 Mar 2013 20:11:03 -0000 RXhhY3RseSwgdGhhdCdzIG15IHVuZGVyc3RhbmRpbmcgYXMgd2VsbC4NCg0KLS0tLS3Tyrz+1K28 /i0tLS0tDQq3orz+yMs6IENoYXJsZXMgRWNrZWwgKGVja2VsY3UpIFttYWlsdG86ZWNrZWxjdUBj aXNjby5jb21dIA0Kt6LLzcqxvOQ6IDIwMTPE6jPUwjEyyNUgMTQ6NTENCsrVvP7IyzogUWluIFd1 OyBSb25pIEV2ZW47ICdNYXJ5IEJhcm5lcyc7ICdDTFVFJw0K1vfM4jogUkU6IFtjbHVlXSBDTFVF IERlc2lnbiBUZWFtIG1lZXRpbmcgb24gZm9yIHRvZGF5IC0gTWFyY2ggNHRoDQoNCk1zaWQgaXMg YSBtZWRpYSBzdHJlYW0gSUQsIG5vdCBuZWNlc3NhcmlseSBhIGRldmljZSBJRC4NCmRyYWZ0LWll dGYtbW11c2ljLW1zaWQtMDAgZGVmaW5lcyBhIHNlbWFudGljIGZvciB1c2FnZSB3aXRoIFdlYlJU QyBpbiB3aGljaCBtc2lkIGlzIGEgV2ViUlRDIG1lZGlhIHN0cmVhbS4NCk90aGVyIHNlbWFudGlj cyBtYXkgYmUgZGVmaW5lZCBieSBmdXR1cmUgZHJhZnRzLg0KDQpDaGVlcnMsDQpDaGFybGVzDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUWluIFd1IFttYWlsdG86Ymls bC53dUBodWF3ZWkuY29tXQ0KPiBTZW50OiBUdWVzZGF5LCBNYXJjaCAxMiwgMjAxMyA3OjQ2IEFN DQo+IFRvOiBDaGFybGVzIEVja2VsIChlY2tlbGN1KTsgUm9uaSBFdmVuOyAnTWFyeSBCYXJuZXMn OyAnQ0xVRScNCj4gU3ViamVjdDogtPC4tDogW2NsdWVdIENMVUUgRGVzaWduIFRlYW0gbWVldGlu ZyBvbiBmb3IgdG9kYXkgLSBNYXJjaCA0dGgNCj4gDQo+IE9uZSBjb25mdXNpb24gd2hlbiBJIHJl YWQgY3VsbGVuJ3MgZHJhZnQgYWJvdXQgTVNJRCB1c2FnZT8gSXMgTVNJRCB1c2VkIHRvDQo+IGlk ZW50aWZ5IGVhY2ggbWVkaWEgc3RyZWFtIG9yIElzIE1TSUQgdXNlZCB0byBpZGVudGlmeSBlYWNo IGRldmljZQ0KPiBpZGVudGlmaWVyPw0KPiBJIGNhbiB1bmRlcnN0YW5kIHRoZSBmb3JtZXIgY2Fz ZSwgc2VlbXMgaXQgaXMgcXVpdGUgc2ltaWxhciB0byBtdWx0aS1jaGFubmVsDQo+IGF1ZGlvIGNh c2UuIEJ1dCBJIGFtIGxvc3Qgd2hlbiBNU0lEIGlzIHJlcHVycG9zZWQgYXMgZGV2aWNlIGlkZW50 aWZpZXIuDQo+IA0KPiBSZWdhcmRzIQ0KPiAtUWluDQo+IC0tLS0t08q8/tStvP4tLS0tLQ0KPiC3 orz+yMs6IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9y Z10gtPqx7Q0KPiBDaGFybGVzIEVja2VsIChlY2tlbGN1KQ0KPiC3osvNyrG85DogMjAxM8TqM9TC MTDI1SAyMjozMQ0KPiDK1bz+yMs6IFJvbmkgRXZlbjsgJ01hcnkgQmFybmVzJzsgJ0NMVUUnDQo+ INb3zOI6IFJlOiBbY2x1ZV0gQ0xVRSBEZXNpZ24gVGVhbSBtZWV0aW5nIG9uIGZvciB0b2RheSAt IE1hcmNoIDR0aA0KPiANCj4gWWVzLCBJIGhhZCBhIHNpbWlsYXIgdGhvdWdodC4gSSB0aGluayAo MSkgY291bGQgYmUgbW9kaWZpZWQgdG8gYmUgbGlrZSAoMyksDQo+IHNheWluZyB0aGF0ICIgaXQg TVVTVCB1c2Ugc2VwYXJhdGUgbS1ibG9ja3MgZm9yIGVhY2ggdW5sZXNzIGV4cGxpY2l0bHkNCj4g c2lnbmFsZWQgdG8gYmUgb3RoZXJ3aXNlIChzZWUgU2VjdGlvbiA3LjIpLg0KPiANCj4gQ2hlZXJz LA0KPiBDaGFybGVzDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJv bTogUm9uaSBFdmVuIFttYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbV0NCj4gPiBTZW50OiBT dW5kYXksIE1hcmNoIDEwLCAyMDEzIDg6NTEgUE0NCj4gPiBUbzogQ2hhcmxlcyBFY2tlbCAoZWNr ZWxjdSk7ICdNYXJ5IEJhcm5lcyc7ICdDTFVFJw0KPiA+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gQ0xV RSBEZXNpZ24gVGVhbSBtZWV0aW5nIG9uIGZvciB0b2RheSAtIE1hcmNoIDR0aA0KPiA+DQo+ID4g Q2hhcmxlcywNCj4gPiBXaGVuIHJlYWRpbmcgQ3VsbGVuJ3MgZHJhZnQgSSBhbHNvIHRob3VnaHQg c28gYnV0IGhhZCBhIHByb2JsZW0gd2hlbg0KPiA+IHJlYWRpbmcNCj4gPiB0aGUgZmlyc3QgYnVs bGV0IGluIHNlY3Rpb24gNy4NCj4gPiBUaGVyZSBhcmUgc29tZSBvdGhlciBtaW5vciBpc3N1ZXMg bGlrZSB0aGUgU1NSQyB1c2FnZSBpbiB0aGUgZGlmZmVyZW50DQo+ID4gdG9wb2xvZ2llcy4NCj4g PiBSb25pDQo+ID4NCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IENo YXJsZXMgRWNrZWwgKGVja2VsY3UpIFttYWlsdG86ZWNrZWxjdUBjaXNjby5jb21dDQo+ID4gU2Vu dDogMTEgTWFyY2gsIDIwMTMgMjoyMSBBTQ0KPiA+IFRvOiBSb25pIEV2ZW47ICdNYXJ5IEJhcm5l cyc7ICdDTFVFJw0KPiA+IFN1YmplY3Q6IFJFOiBbY2x1ZV0gQ0xVRSBEZXNpZ24gVGVhbSBtZWV0 aW5nIG9uIGZvciB0b2RheSAtIE1hcmNoIDR0aA0KPiA+DQo+ID4gSGkgUm9uaSwNCj4gPg0KPiA+ IEkgaGFkIGEgbG9vayBhdCB5b3VyIGRyYWZ0LCBhbmQgSSBsaWtlIGl0LiBJIHRoaW5rIGl0IGFs aWduZWQgd2VsbCB3aXRoDQo+ID4gZHJhZnQtamVubmluZ3MtcnRjd2ViLXBsYW4tMDEsIGFuZCBJ IGFncmVlIHdpdGggeW91ciByZWNvbW1lbmRhdGlvbiBpbg0KPiA2LjINCj4gPiBmb3IgIG9uZSBv ciBtdWx0aXBsZSBSVFAgc3RyZWFtcyBhcyB3ZWxsIGFzIHlvdXIgYXNzZXNzbWVudCBhdCB0aGUg ZW5kIG9mDQo+ID4gc2VjdGlvbiAzIHRoYXQgbmVlZGluZyB0byBjb252ZXkgYWxsIFNTUkNzIGlu IFNEUCB3aWxsIG5vdCBzY2FsZSB3ZWxsIGZvcg0KPiA+IGxhcmdlIGNvbmZlcmVuY2VzLg0KPiA+ DQo+ID4gQ2hlZXJzLA0KPiA+IENoYXJsZXMNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gPiA+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4gPiBPZiBSb25pIEV2ZW4NCj4gPiA+IFNl bnQ6IFRodXJzZGF5LCBNYXJjaCAwNywgMjAxMyAxMjo0MyBBTQ0KPiA+ID4gVG86ICdNYXJ5IEJh cm5lcyc7ICdDTFVFJw0KPiA+ID4gU3ViamVjdDogUmU6IFtjbHVlXSBDTFVFIERlc2lnbiBUZWFt IG1lZXRpbmcgb24gZm9yIHRvZGF5IC0gTWFyY2ggNHRoDQo+ID4gPg0KPiA+ID4gSGksDQo+ID4g PiBJIGFtIHNvcnJ5IEkgbWlzc2VkIHRoZSBtZWV0aW5nLg0KPiA+ID4gT24gdGhlIFNEUCBzdWJq ZWN0DQo+ID4gPiBKb25hdGhhbiwgUWluIGFuZCBJIHN1Ym1pdHRlZCBhIGRvY3VtZW50IHRvIE1N VVNJQw0KPiA+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZXZlbi1tbXVzaWMt bXVsdGlwbGUtc3RyZWFtcy0wMiB0aGF0DQo+ID4gPiB0cmllcyB0byBhZGRyZXNzIGFsc28gdGhl IENMVUUgY29uY2VybnMuDQo+ID4gPiBJdCB3aWxsIGFsc28gYmUgZGlzY3Vzc2VkIGluIHRoZSBN TVVTSUMgc2Vzc2lvbiBhcyB3ZWxsIGFzIHRoZSBvbmUgeW91DQo+ID4gPiBtZW50aW9uZWQgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWplbm5pbmdzLXJ0Y3dlYi1wbGFuLTAxDQo+ ID4gPiBUaGlzIHRvcGljIHdhcyBkaXNjdXNzZWQgaW4gdGhlIE1NVVNJQyBpbnRlcmltIG1lZXRp bmcgYW5kIGl0IGlzDQo+ID4gPiBpbXBvcnRhbnQgdGhhdCB0aGUgQ0xVRSBpbnB1dCBzaG91bGQg YmUgYWRkcmVzc2VkLCBwbGVhc2UgdHJ5IHRvDQo+ID4gPiBhdHRlbmQgYWxzbyB0aGUgTU1VU0lD IHNlc3Npb25zIChUdWVzZGF5IGFuZCBGcmlkYXkgKGZvbGxvd2luZw0KPiA+ID4gQVZUZXh0KSBS b25pDQo+ID4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206 IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQo+ID4gPiBPZiBNYXJ5IEJhcm5lcw0KPiA+ID4gU2VudDogMDcgTWFyY2gsIDIwMTMg MjoxNyBBTQ0KPiA+ID4gVG86IENMVUUNCj4gPiA+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gQ0xVRSBE ZXNpZ24gVGVhbSBtZWV0aW5nIG9uIGZvciB0b2RheSAtIE1hcmNoIDR0aA0KPiA+ID4NCj4gPiA+ IEhpIGFsbCwNCj4gPiA+DQo+ID4gPiBIZXJlIGlzIGEgc3VtbWFyeSBvZiBNb25kYXkncyBtZWV0 aW5nLg0KPiA+ID4NCj4gPiA+IEF0dGVuZGVlczogTWFyeSBCYXJuZXMsIE1hcmsgRHVja3dvcnRo LCBSb2IgSGFuc2VuLCBQYXVsIEt5eml2YXQsDQo+ID4gPiBTaW1vbiBQaWV0cm8tUm9tYW5vDQo+ ID4gPg0KPiA+ID4gTm90ZXM6DQo+ID4gPiAtLS0tLS0tLS0NCj4gPiA+IFRoZSBvYmplY3RpdmUg b2YgdGhlIG1lZXRpbmcgd2FzIHRvIHJldmlldyB0aGUgcGxhbnMgYW5kIGFyZWFzIG9mDQo+ID4g PiBmb2N1cyBmb3IgSUVURi04Ni4NCj4gPiA+DQo+ID4gPiBGcmFtZXdvcms6DQo+ID4gPiAtIHdp dGggcmVnYXJkcyB0byBTdGVwaGFuJ3MgcG9ydGlvbiBvbiB0aGUgYWdlbmRhLCB0aGUgZXhwZWN0 YXRpb24gd2FzDQo+ID4gPiB0byBnZXQgYW4gdXBkYXRlIG9uIHRoZSByZXdvcmsgYW5kIHdheSBm b3J3YXJkLg0KPiA+ID4NCj4gPiA+IC0gd2UgZGlzY3Vzc2VkIHRoZSBpbmNvcnBvcmF0aW9uIG9m IENocmlzdGlhbidzIHN1Z2dlc3Rpb25zIChwZXIgdGhlDQo+ID4gPiBkaXNjdXNzaW9uIG9mIGRy YWZ0ICApIGludG8gdGhlIGZyYW1ld29yay4gIEFjdGlvbjogTWFyayB0byByZXZpZXcgYW5kDQo+ ID4gPiBkZXRlcm1pbmUgaWYvd2hhdCBjaGFuZ2VzIGFyZSByZXF1aXJlZCBmb3IgdGhlIGZyYW1l d29yaw0KPiA+ID4NCj4gPiA+IC0gTWFyayBub3RlZCB0aGF0IHRoZXJlIGFyZSBzb21lIGlzc3Vl cyBpbiB0aGUgdHJhY2tlciB0aGF0IHNob3VsZCBiZQ0KPiA+ID4gY2xvc2VkLiBBY3Rpb246IGNo YWlycyByZXZpZXcgZW1haWxzIGFuZCBjbG9zZSByZWxhdGVkIGlzc3Vlcw0KPiA+ID4NCj4gPiA+ IC0gU2ltdWx0YW5lb3VzIHNldHM6IGl0IGFwcGVhcnMgdGhlIGRpc2N1c3Npb24gb24gdGhlIGxp c3QgaXMgY29udmVyZ2luZy4NCj4gPiA+IE1hcms6IHJldmlldyBhbmQgZGV0ZXJtaW5lIGZyYW1l d29yayBpbXBhY3RzLg0KPiA+ID4NCj4gPiA+IC0gUGF1bCBub3RlZCB0aGF0IFN0ZXBoYW4gaGFk IHNlbnQgYW4gZW1haWwgb24gRlcgaXNzdWVzLCBtb3N0IG9mDQo+ID4gPiB3aGljaCByZWFsbHkg bmVlZCB0byBiZSByZXNvbHZlZCBpbiBzb2x1dGlvbiBkb2N1bWVudHMNCj4gPiA+DQo+ID4gPiBT aWduYWxpbmcvc29sdXRpb246DQo+ID4gPiAtIE5vdGUgdGhhdCBKb25hdGhhbiBoYXMgcHJvZHVj ZWQgYSBkcmFmdCB3aGljaCB3YXMgYSByZXN1bHQgb2YgdGhlDQo+ID4gPiBhY3Rpb24gaXRlbSBm cm9tIElFVEYtODUgZm9yIHRoZSBSVENXRUIvQ0xVRSBmb2xrcyB0byB3b3JrIHRvZ2V0aGVyDQo+ ID4gPiBmb3IgYSBtb2RlbCBmb3INCj4gPiA+IFJUUDoNCj4gPiA+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtbGVubm94LXJhaWFyZWEtcnRwLWdyb3VwaW5nLXRheG9ub215LQ0KPiAwMC50 DQo+ID4gPiB4dA0KPiA+ID4NCj4gPiA+IC0gSW4gdGVybXMgb2YgdGhlIFNpZ25hbGluZyBwb3J0 aW9uIG9mIHRoZSBhZ2VuZGEgb24gVHVlc2RheSwgUGF1bA0KPiA+ID4gd2lsbCBwcm92aWRlIGFu IG92ZXJ2aWV3L3VwZGF0ZSBvbiB0aGUgY3VycmVudCBzaWduYWxpbmcgc29sdXRpb24NCj4gPiBk b2N1bWVudC4NCj4gPiA+IFRoYXQNCj4gPiA+IHdpbGwgbGVhZCBpbnRvIFJvYidzIGRyYWZ0IHNw ZWNpZmljYWxseSBhbmFseXppbmcgU0RQIHVzYWdlLg0KPiA+ID4NCj4gPiA+IEFsc28sIGZvbGtz IHNob3VsZCByZWFkIHRoaXMgZG9jdW1lbnQgd2hpY2ggaWRlbnRpZmllcyByZXF1aXJlbWVudHMN Cj4gPiA+IHNvbWUgb2Ygd2hpY2ggYXJlIGFwcGxpY2FibGUgdG8gQ0xVRToNCj4gPiA+IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWplbm5pbmdzLXJ0Y3dlYi1wbGFuLTAxDQo+ID4g Pg0KPiA+ID4gSXQgaXMgb24gdGhlIE1NVVNJQyBXRyBhZ2VuZGEgZm9yIGRpc2N1c3Npb24gb24g RnJpZGF5Og0KPiA+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzg2L2Fn ZW5kYS9tbXVzaWMvDQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IE1hcnkuDQo+ID4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gY2x1 ZSBtYWlsaW5nIGxpc3QNCj4gPiA+IGNsdWVAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBjbHVlIG1haWxpbmcgbGlz dA0KPiA+ID4gY2x1ZUBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jbHVlDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From Christian.Groves@nteczone.com Tue Mar 12 23:47:01 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 C5AC421F8D07 for ; Tue, 12 Mar 2013 23:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.343 X-Spam-Level: * X-Spam-Status: No, score=1.343 tagged_above=-999 required=5 tests=[AWL=-3.692, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 ffujUAuTMosh for ; Tue, 12 Mar 2013 23:47:01 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id E561E21F8D02 for ; Tue, 12 Mar 2013 23:47:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAN0fQFF20f7u/2dsb2JhbAANNogVvGKBXoMcAQEBBAEBAS8BIBsKDQQJAhEEAQEBBAUWCAUCCQMCAQIBFR8GAwgTBgIBAYgclCqaEmsIkjcXgR+IWYNegSwSBoIjgRcDiEKPM5J1gVY Received: from ppp118-209-254-238.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.254.238]) by ipmail06.adl2.internode.on.net with ESMTP; 13 Mar 2013 17:16:55 +1030 Message-ID: <514020D8.3000203@nteczone.com> Date: Wed, 13 Mar 2013 17:46:48 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C08828047CBFA9@xmb-aln-x08.cisco.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [clue] =?gb2312?b?tPC4tDogIEFjdGl2ZSBzcGVha2VyIGEgcm9sZT8=?= 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, 13 Mar 2013 06:47:01 -0000 Hello Is it really needed to indicate via the CLUE signalling channel the "2nd recent speaker", "3rd recent speaker" etc? It seems that this information could be utilised by endpoints without CLUE. I think it makes sense to have role information in CLUE as a means to select captures to establish media streams for but utilising CLUE for keeping lists of past speakers? Regards, Christian On 12/03/2013 10:40 PM, Qin Wu wrote: > -----ÓʼþÔ­¼þ----- > ·¢¼þÈË: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] ´ú±í Charles Eckel (eckelcu) > ·¢ËÍʱ¼ä: 2013Äê3ÔÂ10ÈÕ 20:21 > ÊÕ¼þÈË: Christer Holmberg; Roni Even; clue@ietf.org > Ö÷Ìâ: Re: [clue] Active speaker a role? > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: Thursday, March 07, 2013 3:32 AM >> To: Roni Even; clue@ietf.org >> Subject: Re: [clue] Active speaker a role? >> >> Hi, >> >> >> >>> This is a point I made in the past that for switched capture it may be good >> to know what is the policy, can be active speaker, time switch (round robin) >> or other methods. >> >> >> >> Correct. So, the question is whether that policy can be seen as a "role". >> >> >> >> There could also be "2nd recent speaker", "3rd recent speaker" etc, but >> instead of defining a separate role for each of them, maybe we could have >> an attribute value, e.g. "recent-speaker=2". > How about addressing this using something similar to the multiple-render attribute proposed in: > http://tools.ietf.org/id/draft-jennings-rtcweb-plan-01.txt > > In this case, you would have the role of active speaker and multiple-render=3, or however many active speakers can be sent/received. > > [Qin]: Sorry to chime in, it is not clear to me why the attribute multiple-render is really needed? Is this attributed used to deal with simulcast case? > Is "multiple streams are sent at the same time" same as "multiple streams are rendered at the same time"? > Why " max-send-ssrc" and " max-recv-ssrc" can not be used for this purpose? > Please correct me if I miss something. > > Cheers, > Charles > >> >> This type of functionality is very important for devices with a limited >> number of streams, screens etc - it non-telepresence rooms. >> >> >> >>> As for your second question advertisement is what can be sent, you >> probably meant that the configure message should allow to select a specific >> switch policy, I think that the configure can only ask for something that was >> advertised >> >> >> >> Yes. >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: 07 March, 2013 10:19 AM >> To: clue@ietf.org >> Subject: [clue] Active speaker a role? >> >> >> >> Hi, >> >> >> >> A couple of questions related to the capture attribute draft. >> >> >> >> Q1. >> >> >> >> Assume you have a MCU, which collects streams from multiple endpoints, >> and provides the active speaker to a single screen entity. So, the content >> will change as the most active changes, but the capture provided by the >> MCU will be the same. >> >> >> >> So, the "role" of this capture would be "active speaker". Or? >> >> >> >> >> >> Q2. >> >> >> >> I assume that capture attribute can also be used during the advertisement >> phase. Ie a single entity can indicate that it is able to receive a stream, >> where it want the content to be the "active speaker" role. Or? >> >> >> >> >> >> Regards, >> >> >> >> Christer >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Mar 13 08:06: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 3870D21F8ED3 for ; Wed, 13 Mar 2013 08:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-4.681, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 T2TDFyW+eIJW for ; Wed, 13 Mar 2013 08:06:26 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 168D521F8E77 for ; Wed, 13 Mar 2013 08:06:24 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-bb-514095ed823e Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 61.96.19728.DE590415; Wed, 13 Mar 2013 16:06:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 16:06:21 +0100 From: Christer Holmberg To: Christian Groves , clue_ietf.org Thread-Topic: =?gb2312?B?W2NsdWVdILTwuLQ6ICBBY3RpdmUgc3BlYWtlciBhIHJvbGU/?= Thread-Index: AQHOH7aVtwghnBcsPE2GbG471vbzOpijuTf4 Date: Wed, 13 Mar 2013 15:06:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B124D42@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B11458F@ESESSMB209.ericsson.se> <05d701ce1b11$59408e40$0bc1aac0$@gmail.com> <7594FB04B1934943A5C02806D1A2204B11498C@ESESSMB209.ericsson.se> <92B7E61ADAC1BB4F941F943788C08828047CBFA9@xmb-aln-x08.cisco.com> , <514020D8.3000203@nteczone.com> In-Reply-To: <514020D8.3000203@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B124D42ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje67qQ6BBl13+Sy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJVxrfkFe8GF/IrTq/axNjA2pXUxcnJICJhI 9F//zgJhi0lcuLeerYuRi0NI4BCjxOvORmYIZzGjxNov35m6GDk42AQsJLr/aYM0iAiEStyf 1sUGYgsL+EncvnGYCSLuLXFu/gU2CNtI4kTLK7A4i4CqRPvkn2DLeIFqnh1fxwox/xWTRPuP 14wgCU4BHYm90y6ygtiMQBd9P7UGrJlZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8rRE2+xP9L P1ghFghKnJz5hGUCo/AsJO2zkJTNQlIGEdeSmNfwG6pGUWJK90N2CFtT4srkQ1C2tsSyha+Z FzCyr2Jkz03MzEkvN9rECIySg1t+q+5gvHNO5BCjNAeLkjhvuOuFACGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2M+lsS4xT8SmUuv31RFrf578rAowktYYoB8brmQoGLVn2+/sktlc2+PP6e ytqC7xzqWd3zA/Ut1V2zPXMetJTN+cv4poJH3N9t89Jfxu+YuNx+lubq/nsz4aA0x/H9gva3 nuV9OjyNSV4spWpZQMidljtNLXtz77PGOiQ/zvLf+9LhyJ7dKVZKLMUZiYZazEXFiQBTdMu0 YAIAAA== Subject: Re: [clue] =?gb2312?b?tPC4tDogIEFjdGl2ZSBzcGVha2VyIGEgcm9sZT8=?= 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, 13 Mar 2013 15:06:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B124D42ESESSMB209ericsso_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNCkl0IGlzIG5vdCBhYm91dCBrZWVwaW5nIGEgbGlzdC4NCg0KVGhlIE1DVSBpcyBwcm92 aWRpbmcgbWVkaWEgc3RyZWFtcyByZXByZXNlbnRpbmcgdGhlIHByZXZpb3VzIHNwZWFrZXJzLiBJ biBhIHR5cGljYWwgdXNlLWNhc2UgdGhleSBhcmUgc2hvd24gYXMgdGh1bWJuYWlscy4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNClNlbnQgZnJvbSBXaW5kb3dzIHVzaW5nIFRvdWNoRG93 biAod3d3Lm5pdHJvZGVzay5jb20pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBDaHJpc3RpYW4gR3JvdmVzIFtDaHJpc3RpYW4uR3JvdmVzQG50ZWN6b25lLmNvbV0NClRvOiBj bHVlQGlldGYub3JnIFtjbHVlQGlldGYub3JnXQ0KU3ViamVjdDogUmU6IFtjbHVlXSC08Li0OiBB Y3RpdmUgc3BlYWtlciBhIHJvbGU/DQpIZWxsbw0KDQpJcyBpdCByZWFsbHkgbmVlZGVkIHRvIGlu ZGljYXRlIHZpYSB0aGUgQ0xVRSBzaWduYWxsaW5nIGNoYW5uZWwgdGhlICIybmQNCnJlY2VudCBz cGVha2VyIiwgIjNyZCByZWNlbnQgc3BlYWtlciIgZXRjPyBJdCBzZWVtcyB0aGF0IHRoaXMNCmlu Zm9ybWF0aW9uIGNvdWxkIGJlIHV0aWxpc2VkIGJ5IGVuZHBvaW50cyB3aXRob3V0IENMVUUuIEkg dGhpbmsgaXQNCm1ha2VzIHNlbnNlIHRvIGhhdmUgcm9sZSBpbmZvcm1hdGlvbiBpbiBDTFVFIGFz IGEgbWVhbnMgdG8gc2VsZWN0DQpjYXB0dXJlcyB0byBlc3RhYmxpc2ggbWVkaWEgc3RyZWFtcyBm b3IgYnV0IHV0aWxpc2luZyBDTFVFIGZvciBrZWVwaW5nDQpsaXN0cyBvZiBwYXN0IHNwZWFrZXJz Pw0KDQpSZWdhcmRzLCBDaHJpc3RpYW4NCg0KT24gMTIvMDMvMjAxMyAxMDo0MCBQTSwgUWluIFd1 IHdyb3RlOg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBjbHVlLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gQ2hhcmxlcyBFY2tlbCAo ZWNrZWxjdSkNCj4gt6LLzcqxvOQ6IDIwMTPE6jPUwjEwyNUgMjA6MjENCj4gytW8/sjLOiBDaHJp c3RlciBIb2xtYmVyZzsgUm9uaSBFdmVuOyBjbHVlQGlldGYub3JnDQo+INb3zOI6IFJlOiBbY2x1 ZV0gQWN0aXZlIHNwZWFrZXIgYSByb2xlPw0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IGNsdWUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNsdWUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+PiBDaHJpc3RlciBIb2xtYmVyZw0KPj4gU2VudDogVGh1 cnNkYXksIE1hcmNoIDA3LCAyMDEzIDM6MzIgQU0NCj4+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0 Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gQWN0aXZlIHNwZWFrZXIgYSByb2xlPw0KPj4N Cj4+IEhpLA0KPj4NCj4+DQo+Pg0KPj4+IFRoaXMgaXMgYSBwb2ludCBJIG1hZGUgaW4gdGhlIHBh c3QgdGhhdCBmb3Igc3dpdGNoZWQgY2FwdHVyZSBpdCBtYXkgYmUgZ29vZA0KPj4gdG8ga25vdyB3 aGF0IGlzIHRoZSBwb2xpY3ksIGNhbiBiZSBhY3RpdmUgc3BlYWtlciwgdGltZSBzd2l0Y2ggKHJv dW5kIHJvYmluKQ0KPj4gb3Igb3RoZXIgbWV0aG9kcy4NCj4+DQo+Pg0KPj4NCj4+IENvcnJlY3Qu IFNvLCB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB0aGF0IHBvbGljeSBjYW4gYmUgc2VlbiBhcyBh ICJyb2xlIi4NCj4+DQo+Pg0KPj4NCj4+IFRoZXJlIGNvdWxkIGFsc28gYmUgIjJuZCByZWNlbnQg c3BlYWtlciIsICIzcmQgcmVjZW50IHNwZWFrZXIiIGV0YywgYnV0DQo+PiBpbnN0ZWFkIG9mIGRl ZmluaW5nIGEgc2VwYXJhdGUgcm9sZSBmb3IgZWFjaCBvZiB0aGVtLCBtYXliZSB3ZSBjb3VsZCBo YXZlDQo+PiBhbiBhdHRyaWJ1dGUgdmFsdWUsIGUuZy4gInJlY2VudC1zcGVha2VyPTIiLg0KPiBI b3cgYWJvdXQgYWRkcmVzc2luZyB0aGlzIHVzaW5nIHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoZSBt dWx0aXBsZS1yZW5kZXIgYXR0cmlidXRlIHByb3Bvc2VkIGluOg0KPiBodHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaWQvZHJhZnQtamVubmluZ3MtcnRjd2ViLXBsYW4tMDEudHh0DQo+DQo+IEluIHRoaXMg Y2FzZSwgeW91IHdvdWxkIGhhdmUgdGhlIHJvbGUgb2YgYWN0aXZlIHNwZWFrZXIgYW5kIG11bHRp cGxlLXJlbmRlcj0zLCBvciBob3dldmVyIG1hbnkgYWN0aXZlIHNwZWFrZXJzIGNhbiBiZSBzZW50 L3JlY2VpdmVkLg0KPg0KPiBbUWluXTogU29ycnkgdG8gY2hpbWUgaW4sIGl0IGlzIG5vdCBjbGVh ciB0byBtZSB3aHkgdGhlIGF0dHJpYnV0ZSBtdWx0aXBsZS1yZW5kZXIgaXMgcmVhbGx5IG5lZWRl ZD8gSXMgdGhpcyBhdHRyaWJ1dGVkIHVzZWQgdG8gZGVhbCB3aXRoIHNpbXVsY2FzdCBjYXNlPw0K PiBJcyAibXVsdGlwbGUgc3RyZWFtcyBhcmUgc2VudCBhdCB0aGUgc2FtZSB0aW1lIiBzYW1lIGFz ICJtdWx0aXBsZSBzdHJlYW1zIGFyZSByZW5kZXJlZCBhdCB0aGUgc2FtZSB0aW1lIj8NCj4gV2h5 ICIgbWF4LXNlbmQtc3NyYyIgYW5kICIgbWF4LXJlY3Ytc3NyYyIgY2FuIG5vdCBiZSB1c2VkIGZv ciB0aGlzIHB1cnBvc2U/DQo+IFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkgbWlzcyBzb21ldGhpbmcu DQo+DQo+IENoZWVycywNCj4gQ2hhcmxlcw0KPg0KPj4NCj4+IFRoaXMgdHlwZSBvZiBmdW5jdGlv bmFsaXR5IGlzIHZlcnkgaW1wb3J0YW50IGZvciBkZXZpY2VzIHdpdGggYSBsaW1pdGVkDQo+PiBu dW1iZXIgb2Ygc3RyZWFtcywgc2NyZWVucyBldGMgLSBpdCBub24tdGVsZXByZXNlbmNlIHJvb21z Lg0KPj4NCj4+DQo+Pg0KPj4+IEFzIGZvciB5b3VyIHNlY29uZCBxdWVzdGlvbiBhZHZlcnRpc2Vt ZW50IGlzIHdoYXQgY2FuIGJlIHNlbnQsIHlvdQ0KPj4gcHJvYmFibHkgbWVhbnQgdGhhdCB0aGUg Y29uZmlndXJlIG1lc3NhZ2Ugc2hvdWxkIGFsbG93IHRvIHNlbGVjdCBhIHNwZWNpZmljDQo+PiBz d2l0Y2ggcG9saWN5LCBJIHRoaW5rIHRoYXQgdGhlIGNvbmZpZ3VyZSBjYW4gb25seSBhc2sgZm9y IHNvbWV0aGluZyB0aGF0IHdhcw0KPj4gYWR2ZXJ0aXNlZA0KPj4NCj4+DQo+Pg0KPj4gWWVzLg0K Pj4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+Pg0KPj4NCj4+IENocmlzdGVyDQo+Pg0KPj4N Cj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gRnJvbTogY2x1ZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86Y2x1ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4+IENocmlzdGVyIEhvbG1i ZXJnDQo+PiBTZW50OiAwNyBNYXJjaCwgMjAxMyAxMDoxOSBBTQ0KPj4gVG86IGNsdWVAaWV0Zi5v cmcNCj4+IFN1YmplY3Q6IFtjbHVlXSBBY3RpdmUgc3BlYWtlciBhIHJvbGU/DQo+Pg0KPj4NCj4+ DQo+PiBIaSwNCj4+DQo+Pg0KPj4NCj4+IEEgY291cGxlIG9mIHF1ZXN0aW9ucyByZWxhdGVkIHRv IHRoZSBjYXB0dXJlIGF0dHJpYnV0ZSBkcmFmdC4NCj4+DQo+Pg0KPj4NCj4+IFExLg0KPj4NCj4+ DQo+Pg0KPj4gQXNzdW1lIHlvdSBoYXZlIGEgTUNVLCB3aGljaCBjb2xsZWN0cyBzdHJlYW1zIGZy b20gbXVsdGlwbGUgZW5kcG9pbnRzLA0KPj4gYW5kIHByb3ZpZGVzIHRoZSBhY3RpdmUgc3BlYWtl ciB0byBhIHNpbmdsZSBzY3JlZW4gZW50aXR5LiBTbywgdGhlIGNvbnRlbnQNCj4+IHdpbGwgY2hh bmdlIGFzIHRoZSBtb3N0IGFjdGl2ZSBjaGFuZ2VzLCBidXQgdGhlIGNhcHR1cmUgcHJvdmlkZWQg YnkgdGhlDQo+PiBNQ1Ugd2lsbCBiZSB0aGUgc2FtZS4NCj4+DQo+Pg0KPj4NCj4+IFNvLCB0aGUg InJvbGUiIG9mIHRoaXMgY2FwdHVyZSB3b3VsZCBiZSAiYWN0aXZlIHNwZWFrZXIiLiBPcj8NCj4+ DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gUTIuDQo+Pg0KPj4NCj4+DQo+PiBJIGFzc3VtZSB0aGF0IGNh cHR1cmUgYXR0cmlidXRlIGNhbiBhbHNvIGJlIHVzZWQgZHVyaW5nIHRoZSBhZHZlcnRpc2VtZW50 DQo+PiBwaGFzZS4gSWUgYSBzaW5nbGUgZW50aXR5IGNhbiBpbmRpY2F0ZSB0aGF0IGl0IGlzIGFi bGUgdG8gcmVjZWl2ZSBhIHN0cmVhbSwNCj4+IHdoZXJlIGl0IHdhbnQgdGhlIGNvbnRlbnQgdG8g YmUgdGhlICJhY3RpdmUgc3BlYWtlciIgcm9sZS4gT3I/DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+ IFJlZ2FyZHMsDQo+Pg0KPj4NCj4+DQo+PiBDaHJpc3Rlcg0KPj4NCj4+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNsdWUgbWFpbGluZyBsaXN0 DQo+IGNsdWVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jbHVlDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IGNsdWUgbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpjbHVlIG1haWxpbmcgbGlzdA0KY2x1ZUBpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= --_000_7594FB04B1934943A5C02806D1A2204B124D42ESESSMB209ericsso_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi,
 
It is not about keeping a list.
 
The MCU is providing media streams representing= the previous speakers. In a typical use-case they are shown as thumbnails.=
 
Regards,
 
Christer
 


Sent from Windows using TouchDown= (www.nitrodesk.com)

-----Original Message-----
From: Christian Groves [Christian.Groves@nteczone.com]
To: clue@ietf.org [clue@ietf.org]
Subject: Re: [clue] =B4=F0=B8=B4: Active speaker a role?
Hello

Is it really needed to indicate via the CLUE signalling channel the "2= nd
recent speaker", "3rd recent speaker" etc? It seems that thi= s
information could be utilised by endpoints without CLUE. I think it
makes sense to have role information in CLUE as a means to select
captures to establish media streams for but utilising CLUE for keeping
lists of past speakers?

Regards, Christian

On 12/03/2013 10:40 PM, Qin Wu wrote:
> -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] =B4=FA=B1=ED Charles Eckel = (eckelcu)
> =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA3=D4=C210=C8=D5 20:21
> =CA=D5=BC=FE=C8=CB: Christer Holmberg; Roni Even; clue@ietf.org
> =D6=F7=CC=E2: Re: [clue] Active speaker a role?
>
>> -----Original Message-----
>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>> Christer Holmberg
>> Sent: Thursday, March 07, 2013 3:32 AM
>> To: Roni Even; clue@ietf.org
>> Subject: Re: [clue] Active speaker a role?
>>
>> Hi,
>>
>>
>>
>>> This is a point I made in the past that for switched capture i= t may be good
>> to know what is the policy, can be active speaker, time switch (ro= und robin)
>> or other methods.
>>
>>
>>
>> Correct. So, the question is whether that policy can be seen as a = "role".
>>
>>
>>
>> There could also be "2nd recent speaker", "3rd rece= nt speaker" etc, but
>> instead of defining a separate role for each of them, maybe we cou= ld have
>> an attribute value, e.g. "recent-speaker=3D2".
> How about addressing this using something similar to the multiple-rend= er attribute proposed in:
> http://tools.ietf.org/id/draft-jennings-rtcweb-plan-01.txt
>
> In this case, you would have the role of active speaker and multiple-r= ender=3D3, or however many active speakers can be sent/received.
>
> [Qin]: Sorry to chime in, it is not clear to me why the attribute mult= iple-render is really needed? Is this attributed used to deal with simulcas= t case?
> Is "multiple streams are sent at the same time" same as &quo= t;multiple streams are rendered at the same time"?
> Why " max-send-ssrc" and " max-recv-ssrc" can not = be used for this purpose?
> Please correct me if I miss something.
>
> Cheers,
> Charles
> 
>>
>> This type of functionality is very important for devices with a li= mited
>> number of streams, screens etc - it non-telepresence rooms.
>>
>>
>>
>>> As for your second question advertisement is what can be sent,= you
>> probably meant that the configure message should allow to select a= specific
>> switch policy, I think that the configure can only ask for somethi= ng that was
>> advertised
>>
>>
>>
>> Yes.
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
>>
>>
>>
>>
>>
>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>> Christer Holmberg
>> Sent: 07 March, 2013 10:19 AM
>> To: clue@ietf.org
>> Subject: [clue] Active speaker a role?
>>
>>
>>
>> Hi,
>>
>>
>>
>> A couple of questions related to the capture attribute draft.
>>
>>
>>
>> Q1.
>>
>>
>>
>> Assume you have a MCU, which collects streams from multiple endpoi= nts,
>> and provides the active speaker to a single screen entity. So, the= content
>> will change as the most active changes, but the capture provided b= y the
>> MCU will be the same.
>>
>>
>>
>> So, the "role" of this capture would be "active spe= aker". Or?
>>
>>
>>
>>
>>
>> Q2.
>>
>>
>>
>> I assume that capture attribute can also be used during the advert= isement
>> phase. Ie a single entity can indicate that it is able to receive = a stream,
>> where it want the content to be the "active speaker" rol= e. Or?
>>
>>
>>
>>
>>
>> Regards,
>>
>>
>>
>> Christer
>>
>>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.iet= f.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.iet= f.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_7594FB04B1934943A5C02806D1A2204B124D42ESESSMB209ericsso_-- From eckelcu@cisco.com Wed Mar 13 10:47: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 8B4D021F8E43; Wed, 13 Mar 2013 10:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGFgOlgLlLVW; Wed, 13 Mar 2013 10:47:50 -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 B086E21F8E3C; Wed, 13 Mar 2013 10:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1520; q=dns/txt; s=iport; t=1363196869; x=1364406469; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iu1EcE0gbpKef26j5b8F+G6kV8L7K7ORVmVlsJKKKso=; b=TjZ43CMUouvpBdMV5MP837xBZiMuJ91iZGEokp4r4L6Kiud8H4yMnoB7 hbCCLqhgAm75lbncoOOLUGyXnRyVCLXw7Ft+jo83LidsIHVsw2064V9bT X8tEnoUaeVWgDA92E7QQNu7QRBFBK4iHB+IfXKCHwRh4HdHYCeAlkzhmN E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJq6QFGtJXHB/2dsb2JhbABDxFGBWRZ0gioBAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQBDQUIiAwMwmAXjlwmCwcGgllhA5d1j1eDCoIo X-IronPort-AV: E=Sophos;i="4.84,838,1355097600"; d="scan'208";a="186889082" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 13 Mar 2013 17:47:49 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2DHlnxA014608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 17:47:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 12:47:48 -0500 From: "Charles Eckel (eckelcu)" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt Thread-Index: AQHODTtjj34tY141eUeP3HeOLgkEfpikCyTQ Date: Wed, 13 Mar 2013 17:47:48 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D3943@xmb-aln-x08.cisco.com> References: <20130217181935.30724.5333.idtracker@ietfa.amsl.com> In-Reply-To: <20130217181935.30724.5333.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.68.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-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: Wed, 13 Mar 2013 17:47:50 -0000 Perhaps this draft should be added to the agenda for Thursday's session? Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Sunday, February 17, 2013 1:20 PM > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ControLling mUltiple streams for > tElepresence Working Group of the IETF. >=20 > Title : Mapping RTP streams to CLUE media captures > Author(s) : Roni Even > Jonathan Lennox > Filename : draft-ietf-clue-rtp-mapping-00.txt > Pages : 19 > Date : 2013-02-17 >=20 > Abstract: > This document describes mechanisms and recommended practice for > mapping RTP media streams defined in SDP to CLUE media captures. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Wed Mar 13 11:30:10 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 E483121F8EDE for ; Wed, 13 Mar 2013 11:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 wS-clcP+JbUQ for ; Wed, 13 Mar 2013 11:30:09 -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 D2AB821F8EC7 for ; Wed, 13 Mar 2013 11:29:29 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id b25so613657qca.17 for ; Wed, 13 Mar 2013 11:29:22 -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:cc:content-type; bh=2rMOE6Dh2sw5BGVyOvvZBUcc7lqHlYrzMEtjoO8yC6w=; b=Ky1BOLcVmEVvfYogggWIu/wJPMel1t5yk7MetLrBBFRDYOCbcDQbvTzrHECRBqlkeB k6qMpPHKUvhsMHepnR3wyhepgHQ0beJPsIhm63kR4BI7VWcPkotOvGEBFHJkhFha5ZcA M2hhn6zW3OBHm+1//WGg671vRueqYrxbwqY2p8diFm1pnQ3WeruNMPVVPN2aAyrNE4U3 UKIyGsLRXzX7rqH00onWngHPhV4x97VyEqURvef/jgN8tAAeXKUlTVYzNASi5UIq2Wod kSTeguT4CY6RLIAOQU91L/CHVL7dpJKKedUn+AKLMdHY4tuaGNZHPW3gkJEEIYdmVdjm U0zg== MIME-Version: 1.0 X-Received: by 10.49.61.164 with SMTP id q4mr4700317qer.60.1363199362505; Wed, 13 Mar 2013 11:29:22 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Wed, 13 Mar 2013 11:29:22 -0700 (PDT) In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047D3943@xmb-aln-x08.cisco.com> References: <20130217181935.30724.5333.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D3943@xmb-aln-x08.cisco.com> Date: Wed, 13 Mar 2013 13:29:22 -0500 Message-ID: From: Mary Barnes To: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-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: Wed, 13 Mar 2013 18:30:10 -0000 Are there specific issues that you see needing discussion? Roni/Jonathan - is there anything you want to cover in the f2f time? Thanks, Mary. On Wed, Mar 13, 2013 at 12:47 PM, Charles Eckel (eckelcu) wrote: > Perhaps this draft should be added to the agenda for Thursday's session? > > Cheers, > Charles > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Sunday, February 17, 2013 1:20 PM >> To: i-d-announce@ietf.org >> Cc: clue@ietf.org >> Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple streams for >> tElepresence Working Group of the IETF. >> >> Title : Mapping RTP streams to CLUE media captures >> Author(s) : Roni Even >> Jonathan Lennox >> Filename : draft-ietf-clue-rtp-mapping-00.txt >> Pages : 19 >> Date : 2013-02-17 >> >> Abstract: >> This document describes mechanisms and recommended practice for >> mapping RTP media streams defined in SDP to CLUE media captures. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> 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 ietf@meetecho.com Wed Mar 13 16:32:02 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 8DDBE11E816F for ; Wed, 13 Mar 2013 16:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjpEeTkfFd-2 for ; Wed, 13 Mar 2013 16:32:02 -0700 (PDT) Received: from smtpdg7.aruba.it (smtpdg3.aruba.it [62.149.158.233]) by ietfa.amsl.com (Postfix) with ESMTP id D21BD11E816E for ; Wed, 13 Mar 2013 16:32:01 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id BBXz1l0042w8SR601BY0wh; Thu, 14 Mar 2013 00:32:01 +0100 Date: Wed, 13 Mar 2013 19:31:56 -0400 (EDT) From: Meetecho Team To: clue@ietf.org Message-ID: <1266014.21.1363217516732.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20_1858775.1363217516728" Subject: [clue] Meetecho support for CLUE_II session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 23:32:02 -0000 ------=_Part_20_1858775.1363217516728 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the CLUE WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/clue The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_20_1858775.1363217516728-- From pkyzivat@alum.mit.edu Thu Mar 14 04:44: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 6D7B021F8D5B for ; Thu, 14 Mar 2013 04:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.103 X-Spam-Level: X-Spam-Status: No, score=0.103 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_17=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 tMd7mPQWf0jL for ; Thu, 14 Mar 2013 04:44:39 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id 6926021F8D55 for ; Thu, 14 Mar 2013 04:44:39 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta01.emeryville.ca.mail.comcast.net with comcast id BPg21l0031u4NiLA1Pkfc3; Thu, 14 Mar 2013 11:44:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2001:df8:0:128:2006:56e9:cf8b:4ea7]) by omta21.emeryville.ca.mail.comcast.net with comcast id BPkd1l00N2CH3Z58hPkeAX; Thu, 14 Mar 2013 11:44:39 +0000 Message-ID: <5141B825.2070702@alum.mit.edu> Date: Thu, 14 Mar 2013 19:44:37 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <5138E68B.5000003@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1161B0@ESESSMB209.ericsson.se> <5138F39E.5060204@alum.mit.edu> <51395C0F.2010201@nteczone.com> In-Reply-To: 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=1363261479; bh=vgeV2vWpZ2/69nAQfQKs+j2Yi+QUSYH48wpnH/nFthE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Rh5L5gCfo286oi5ILaVIW1xqIg/6dRNzMz57O8tATzt2TcpBRAHdFSc2B/forpgwe k2pLdVQhe8WkxuCt0JjDi56G+OYjA7lX/7/4r3nvpbJIk/UEvK9nXI8pK22Man/k1H EP2rhDN2vmwIicSrIQXU+z8PLAy+VOy9Axh2UV+3xuEPvTW98jgmYFCFm3L+O3wEMZ OheR8c2xRHMIUHQXwpRIkl25X5U8bvYQ11AUkVA3+jqq3Tco+R28/ymXgMilUxnB0+ mcTndYZw13u14SACqGPlXFI92UouakqHvTfBbz8oBhBsX9by182wOFC+4TkyYVFET0 HA3qPKVp+CYSw== Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model 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, 14 Mar 2013 11:44:40 -0000 On 3/12/13 8:25 PM, Richard Barnes wrote: > > > I think this is a very useful taxonomy, and it seems like this group > should focus on (1), at least initially. CLUE is about providing > metadata on how a set of media streams relate to one another, so we > should aspire to clean layering here. The CLUE protocol (1) should be > mostly independent of SDP, as suggested by the last presentation yesterday. > > For example, ISTM that one very positive outcome here would be if it > were possible for me to write an RTCWEB web app for telepresence, where > the browser hands me a collection of media streams and a data channel, > then I use CLUE over the data channel to figure out how to render those > streams (and tell the far side about my streams). Yes!!! That has been one of my objectives. But that also implies that clue's use of SDP be compatible with RTCWEB's. And that too cuts two ways: - whatever RTCWEB requires in SDP in order to properly set up media streams in the browser must be consistent with the way CLUE uses SDP. - any "extra" SDP that CLUE might use had better be settable/ gettable by the javascript in the browser. Of course the signaling the rtcweb app does *might* not be sip (e.g. might be jingle) and *might* not contain actual SDP, but if not then the web server will generally need to map it SIP/SDP, so it amounts to the same thing. Thanks, Paul > --Richard > > > On Thu, Mar 7, 2013 at 10:33 PM, Christian Groves > > > wrote: > > Hello, > > I think part of the problem may be that when people talk about > "CLUE" they actually mean different things. > > For me there's two aspects: 1) CLUE as a signalling protocol, and 2) > how to use CLUE in a SIP network. > > For 1) I can't see any need to incorporate SDP into the CLUE signalling. > For 2) SDP will be required in SIP networks to establish the CLUE > data channel. SDP will also be required to establish the media. > > It would be good for people to clarify what they mean when they are > talking about SDP. > > I personally think the RTCWEB work is a distraction and likewise the > RTPMUX work for the CLUE signalling protocol. RTPMUX is important > for the establishment of media. > > Regards, Christian > > > On 8/03/2013 7:07 AM, Paul Kyzivat wrote: > > (as individual) > > Perhaps we should talk in rtcweb about what we are doing in > clue, and suggest that some of the understanding of what the > multiple streams *mean* in rtcweb should be left as > application-specific. > > Thanks, > Paul > > On 3/8/13 3:48 AM, Mary Barnes wrote: > > On Thu, Mar 7, 2013 at 1:39 PM, Christer Holmberg > > wrote: > > > Hi, > > I agree with Paul. > > My personal starting point is still that the CLUE > signalling should be used for the telepresence > application related stuff, like spatial relationship etc. > > I also don't think that the RTCWEB outcome affect us, as > far as our mechanism is concerned. However, if RTCWEB > loses interest in pushing for SDP and/or RTP extensions > that we also are interested in, WE may have to become > more active in that work. > > [MB] > I wasn't suggesting that their decision as > to the > mechanism would directly impact CLUE. I'm suggesting that > some of the > challenges they are having are due to the fact that they are > trying to > use SDP for something that it really wasn't designed or > envisioned to > be used for. I do believe that some of the issues with SDP > that they > are encountering that is making folks rethink the RTCWEB > decision are > not unlike those that CLUE may have to deal with. I > strongly believe > that decoupling the CLUE application from SDP as much as > possible is a > better path than trying to put so much into SDP (which is a > *similar* > discussion as is happening in RTCWEB in terms of decoupling > the API > from SDP). I understand that we are using SIP for session > setup, so > of course, we will need to use SDP O/A and thus we can't totally > decouple. As we have been discussing for well over a year, the > challenge is how much of the CLUE application information > should be > carried in SDP versus a CLUE specific protocol. > > > We should already be more active in the work and not > expect that we would just use what RTCWEB needs. CLUE > requirements > should be considered equal to those of RTCWEB. I think we > also need > to be very thoughtful as to how we make our decisions so we > don't end > up a year from now with folks questioning the path we chose. > > > > Regards, > > Christer > > > __________________________________________ > From: clue-bounces@ietf.org > [clue-bounces@ietf.org > ] on behalf of Paul > Kyzivat [pkyzivat@alum.mit.edu > ] > Sent: Thursday, 07 March 2013 9:12 PM > To: Mary Barnes > Cc: CLUE > Subject: Re: [clue] RTCWEB: using SDP "blob" and O/A model > > I don't fully agree with Mary on this. > > First, I don't think that discussion in RTCWEB has much > bearing on CLUE. > RTCWEB uses a non-sip signaling model. And it doesn't > even call for use > of SDP in signaling. Rather it only uses SDP for > communication between > the javascript and the browser it runs in. It doesn't > require that the > SDP constructed in one broswer be identical to that seen > in the browser > at the other end. SDP has long been a poor choice for > the purpose we use > it, but we have legacy reasons to continue and efforts > to move to SDPng > failed. It is extremely poor as an abstract conceptual > representation > for an API. So IMO it makes sense to think hard about > whether to use it > in RTCWEB. The argument there is not what to put in SDP > and what to do > another way, it is about whether to use SDP or not. > > But CLUE is mostly SIP-based. We are going to be using > SDP. For us the > question is how much to put in SDP and how much to put > in the CLUE > protocol. I don't think the rtcweb arguments are helpful > about that. > > IMO we should use SDP for the things it does, and > perhaps extend it a > bit for things it *ought* to do, philosophically. SDP > O/A is focused on > two ends negotiating based on what each is prepared to > receive. > Sometimes it talks about what is to be sent, but it > isn't so good about > that. In the end the result of the negotiation defines > characteristics > of what *will* be sent. And that part is important to > some middle boxes, > so we should try hard not to break that. > > Clue is focused on presenting a menu of what *could* be > *sent* and then > selecting from that menu what should be sent, and how. > It is pretty hard > to work out what SDP is required until all that is > known. So I prefer > keeping the division that way - the SDP is only used to > signal the > details to support what will be sent, based on what was > agreed in the > clue signaling. > > In some cases this may lead to conflicts. For instance, > SDP has the > a=content attribute. In our clue data model and > signaling we will have a > much richer mechanism to describe similar > characteristics. IMO we should > not feel a need to exclusively use SDP for this. I don't > know that we > need to use it at all between clue-aware endpoints, > though we ought to > do as much as we can when talking to legacy endpoints. > > So in practice I will probably agree with Mary most of > the time about > what should be in SDP and what should not. > > I'll also observe that the less we depend on SDP the > less trouble we > will have making CLUE work in RTCWEB. > > Thanks, > Paul > > On 3/8/13 2:08 AM, Mary Barnes wrote: > > I really think CLUE folks need to read this thread > and understand the issues: > http://www.ietf.org/mail-__archive/web/rtcweb/current/__msg06612.html > > > While we aren't defining an API, we are defining a > application. I > think it's important to carefully consider the > tradeoffs in terms of > how much is carried in SDP versus how much we can do > with a CLUE > specific protocol. > > > I really, really think that the more we put in SDP, > the less > extensibility we will have for the CLUE application > - I think we > really, really need to carefully weigh the tradeoffs > between tightly > coupling the CLUE application to SDP versus > minimizing the > interactions and duplication of information. > > In one sense, this is a similar problem we faced > with SIP > conferencing. We defined some basic extensions that > worked just fine. > But, it would have been a bear to add all the > additional functionality > for complex scenarios to SIP. Instead, we defined > XCON, which > decouples the conferencing application from the session > setup/signaling protocol. XCON is highly extensible > and flexible and > provides a rich set of application functionality. I > believe we want > to same with CLUE a > > > > Mary. > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From eckelcu@cisco.com Thu Mar 14 07:27:11 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 92DFE21F90C3 for ; Thu, 14 Mar 2013 07:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6PD2g5OMnsW for ; Thu, 14 Mar 2013 07:27:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9A21F90A1 for ; Thu, 14 Mar 2013 07:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2753; q=dns/txt; s=iport; t=1363271227; x=1364480827; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1LyjBygqZY/BiMjSYWPnT8Ys4BcX42/KPpC2Hg1CFOI=; b=fFxiC1JL4VFa0o4tWkXGMpVpfeFbt3+XwzKHCCH40iP6ErSBB5I6FtVC 2W1DPbtQ2iOLCab5lMdN32A5PAz1VoLxb3tbR9zxgTM4LZTMfAJMiUQj6 t8rbyZH+27dUFivCR7SXR58G56b1Gh6hW7qrKOgq/TKF6eW6ai8dPq6cE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGrdQVGtJV2Z/2dsb2JhbABDxHiBYhZ0gioBAQEDAQEBATc0CwwEAgEIEQQBAQEKFAkHIQYLFAkIAgQOBQiHegMJBgy3Ow2JW4xGghkmCwcGgllhA5R4gn+KSYUagwqCKA X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187449305" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2013 14:27:06 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EER68k023343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 14:27:06 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 09:27:06 -0500 From: "Charles Eckel (eckelcu)" To: Mary Barnes Thread-Topic: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt Thread-Index: AQHODTtjj34tY141eUeP3HeOLgkEfpikCyTQgABfkwCAAPm2cA== Date: Thu, 14 Mar 2013 14:27:06 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D4548@xmb-aln-x08.cisco.com> References: <20130217181935.30724.5333.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D3943@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.150.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-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: Thu, 14 Mar 2013 14:27:11 -0000 I have not had a chance to read this version yet. I see it is essentially t= he same as draft-even-clue-rtp-mapping-05. However, there were a fair numbe= r of changes between it and draft-even-clue-rtp-mapping-04. I don't recall = those being discussed. I think it would be worthwhile to do that, if possib= le. One reason for suggesting it is that the existing agenda seemed to be r= elatively light. Cheers, Charles > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: Wednesday, March 13, 2013 2:29 PM > To: Charles Eckel (eckelcu) > Cc: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt >=20 > Are there specific issues that you see needing discussion? >=20 > Roni/Jonathan - is there anything you want to cover in the f2f time? >=20 > Thanks, > Mary. >=20 > On Wed, Mar 13, 2013 at 12:47 PM, Charles Eckel (eckelcu) > wrote: > > Perhaps this draft should be added to the agenda for Thursday's session= ? > > > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >> internet-drafts@ietf.org > >> Sent: Sunday, February 17, 2013 1:20 PM > >> To: i-d-announce@ietf.org > >> Cc: clue@ietf.org > >> Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the ControLling mUltiple streams for > >> tElepresence Working Group of the IETF. > >> > >> Title : Mapping RTP streams to CLUE media captures > >> Author(s) : Roni Even > >> Jonathan Lennox > >> Filename : draft-ietf-clue-rtp-mapping-00.txt > >> Pages : 19 > >> Date : 2013-02-17 > >> > >> Abstract: > >> This document describes mechanisms and recommended practice for > >> mapping RTP media streams defined in SDP to CLUE media captures. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> 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 Thu Mar 14 08:05: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 B44A211E81D0 for ; Thu, 14 Mar 2013 08:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.05 X-Spam-Level: X-Spam-Status: No, score=-102.05 tagged_above=-999 required=5 tests=[AWL=1.549, 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 915nvExU4Us1 for ; Thu, 14 Mar 2013 08:04:58 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8311E8221 for ; Thu, 14 Mar 2013 08:04:45 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id bs12so2899346qab.0 for ; Thu, 14 Mar 2013 08:04:44 -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:cc:content-type:content-transfer-encoding; bh=PrhxSArBz3902vRsRciv7V6hlmgHEmQDDUKB4e0hnHY=; b=f6rC6QQudLVgKsE0FhOLV1gKEFDKfdf9KMY6DIL9rLmrLRCr2UHY1zPOrNc9bDUcXN /81tTm7JB9+cY6TCFKbx61jgg4mjRfpY27x7b8N5sq+wTYrYALqWwqcGrkB+7CjJWi2o xnuHfBUGyC2y2/73mOv+qxqcdqpxlyEqGwubmYX0tJJw1JwXfmWJiNnfY2qdXxHZW/Ir NP6SZIiU1j0CX7mgI2p4Ee9q6SUrom+5QYHKprEx9de41KkyzbgklOK6o6WbLTo7dtJf ewtFLFnTOvpSAdVRsvQx7KP04hWNWpAPIKMuvKVUSS831hNLEzC41OUubxmuEcREl2Ho 3ywg== MIME-Version: 1.0 X-Received: by 10.229.72.130 with SMTP id m2mr457457qcj.122.1363273484709; Thu, 14 Mar 2013 08:04:44 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Thu, 14 Mar 2013 08:04:44 -0700 (PDT) In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047D4548@xmb-aln-x08.cisco.com> References: <20130217181935.30724.5333.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D3943@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C08828047D4548@xmb-aln-x08.cisco.com> Date: Thu, 14 Mar 2013 10:04:44 -0500 Message-ID: From: Mary Barnes To: "Charles Eckel (eckelcu)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-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: Thu, 14 Mar 2013 15:05:04 -0000 This has been discussed at the last IETF and on the mailing list: http://www.ietf.org/proceedings/85/minutes/minutes-85-clue Roni was to incorporate the material from the other rtp usage draft per the action item from the meeting: -- RTP mapping and usage: Roni, Jonathan Lennox (based on draft-even-clue-rtp-mapping and pulling reqs, etc. from draft-lennox-clue-rtp-usage) After that update we did a call to accept that as a WG document: http://www.ietf.org/mail-archive/web/clue/current/msg02337.html You can go back to the mailing list and previous meeting archives as well if you want to understand why there were two separate documents originally - we had lots of discussion of these documents at previous IETF and interim meetings. I have uploaded an updated agenda for today, along with presentations. As indicated in the original agenda, we were waiting for out design team meeting yesterday to figure out the details. Since there have been no issues raised on that document on the mailing list prior to the meeting, I'm not sure it would be too productive. However, if we have time at the end, then you can raise any concerns you might have. Regards, Mary. On Thu, Mar 14, 2013 at 9:27 AM, Charles Eckel (eckelcu) wrote: > I have not had a chance to read this version yet. I see it is essentially= the same as draft-even-clue-rtp-mapping-05. However, there were a fair num= ber of changes between it and draft-even-clue-rtp-mapping-04. I don't recal= l those being discussed. I think it would be worthwhile to do that, if poss= ible. One reason for suggesting it is that the existing agenda seemed to be= relatively light. > > Cheers, > Charles > >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> Sent: Wednesday, March 13, 2013 2:29 PM >> To: Charles Eckel (eckelcu) >> Cc: clue@ietf.org >> Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt >> >> Are there specific issues that you see needing discussion? >> >> Roni/Jonathan - is there anything you want to cover in the f2f time? >> >> Thanks, >> Mary. >> >> On Wed, Mar 13, 2013 at 12:47 PM, Charles Eckel (eckelcu) >> wrote: >> > Perhaps this draft should be added to the agenda for Thursday's sessio= n? >> > >> > Cheers, >> > Charles >> > >> >> -----Original Message----- >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >> >> internet-drafts@ietf.org >> >> Sent: Sunday, February 17, 2013 1:20 PM >> >> To: i-d-announce@ietf.org >> >> Cc: clue@ietf.org >> >> Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt >> >> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> >> directories. >> >> This draft is a work item of the ControLling mUltiple streams for >> >> tElepresence Working Group of the IETF. >> >> >> >> Title : Mapping RTP streams to CLUE media captures >> >> Author(s) : Roni Even >> >> Jonathan Lennox >> >> Filename : draft-ietf-clue-rtp-mapping-00.txt >> >> Pages : 19 >> >> Date : 2013-02-17 >> >> >> >> Abstract: >> >> This document describes mechanisms and recommended practice for >> >> mapping RTP media streams defined in SDP to CLUE media captures. >> >> >> >> >> >> The IETF datatracker status page for this draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping >> >> >> >> There's also a htmlized version available at: >> >> http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00 >> >> >> >> >> >> Internet-Drafts are also available by anonymous FTP at: >> >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> _______________________________________________ >> >> 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 eckelcu@cisco.com Thu Mar 14 11:01:48 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 7DE4B11E8155 for ; Thu, 14 Mar 2013 11:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftbE+9DzSqpS for ; Thu, 14 Mar 2013 11:01:47 -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 9731511E8129 for ; Thu, 14 Mar 2013 11:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4682; q=dns/txt; s=iport; t=1363284107; x=1364493707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wIpLVNVi3I+GrABsYc5KMuaFwIRvPGevEifn0H3/nNE=; b=JxSijRsrO8MiUarX20IgkWoRwYj6yLXl/CF69tS3kzahnCNnqQ/h+YgT NhFvzS9RHVIdlfmTINAqRubOekXZTRJnlV7fztlHIUwEEH64ilwLKJRLV AZMsW7jek4ApI7cZM8NnMrMXqDyFLN5PmcGO4ArQvyDzrFOso29sr83x5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAFkPQlGtJXG8/2dsb2JhbABDxQKBZRZ0gisBAQEEAQEBNzQLDAQCAQgRBAEBAQoUCQchBgsUCQgCBA4FCAGHeQMPDLglDYlbjEyBGYEAJgsCBQaCWWEDlHiCf4pJhRqDCoFzNQ X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187338206" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2013 18:01:47 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EI1lnX027308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Mar 2013 18:01:47 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 13:01:46 -0500 From: "Charles Eckel (eckelcu)" To: Mary Barnes Thread-Topic: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt Thread-Index: AQHODTtjj34tY141eUeP3HeOLgkEfpikCyTQgABfkwCAAPm2cIAAX3MA///dbFA= Date: Thu, 14 Mar 2013 18:01:45 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D4808@xmb-aln-x08.cisco.com> References: <20130217181935.30724.5333.idtracker@ietfa.amsl.com> <92B7E61ADAC1BB4F941F943788C08828047D3943@xmb-aln-x08.cisco.com> <92B7E61ADAC1BB4F941F943788C08828047D4548@xmb-aln-x08.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.120.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-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: Thu, 14 Mar 2013 18:01:48 -0000 WFM. Thanks for bringing me up to date on the state of the draft. Cheers, Charles > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: Thursday, March 14, 2013 11:05 AM > To: Charles Eckel (eckelcu) > Cc: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt >=20 > This has been discussed at the last IETF and on the mailing list: > http://www.ietf.org/proceedings/85/minutes/minutes-85-clue >=20 > Roni was to incorporate the material from the other rtp usage draft > per the action item from the meeting: > -- RTP mapping and usage: Roni, Jonathan Lennox (based on > draft-even-clue-rtp-mapping and pulling reqs, etc. from > draft-lennox-clue-rtp-usage) >=20 > After that update we did a call to accept that as a WG document: > http://www.ietf.org/mail-archive/web/clue/current/msg02337.html >=20 > You can go back to the mailing list and previous meeting archives as > well if you want to understand why there were two separate documents > originally - we had lots of discussion of these documents at previous > IETF and interim meetings. >=20 > I have uploaded an updated agenda for today, along with presentations. > As indicated in the original agenda, we were waiting for out design > team meeting yesterday to figure out the details. >=20 > Since there have been no issues raised on that document on the mailing > list prior to the meeting, I'm not sure it would be too productive. > However, if we have time at the end, then you can raise any concerns > you might have. >=20 > Regards, > Mary. >=20 > On Thu, Mar 14, 2013 at 9:27 AM, Charles Eckel (eckelcu) > wrote: > > I have not had a chance to read this version yet. I see it is essential= ly the > same as draft-even-clue-rtp-mapping-05. However, there were a fair > number of changes between it and draft-even-clue-rtp-mapping-04. I don't > recall those being discussed. I think it would be worthwhile to do that, = if > possible. One reason for suggesting it is that the existing agenda seemed= to > be relatively light. > > > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > >> Sent: Wednesday, March 13, 2013 2:29 PM > >> To: Charles Eckel (eckelcu) > >> Cc: clue@ietf.org > >> Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt > >> > >> Are there specific issues that you see needing discussion? > >> > >> Roni/Jonathan - is there anything you want to cover in the f2f time? > >> > >> Thanks, > >> Mary. > >> > >> On Wed, Mar 13, 2013 at 12:47 PM, Charles Eckel (eckelcu) > >> wrote: > >> > Perhaps this draft should be added to the agenda for Thursday's > session? > >> > > >> > Cheers, > >> > Charles > >> > > >> >> -----Original Message----- > >> >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >> Of > >> >> internet-drafts@ietf.org > >> >> Sent: Sunday, February 17, 2013 1:20 PM > >> >> To: i-d-announce@ietf.org > >> >> Cc: clue@ietf.org > >> >> Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-00.txt > >> >> > >> >> > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > >> >> directories. > >> >> This draft is a work item of the ControLling mUltiple streams for > >> >> tElepresence Working Group of the IETF. > >> >> > >> >> Title : Mapping RTP streams to CLUE media captures > >> >> Author(s) : Roni Even > >> >> Jonathan Lennox > >> >> Filename : draft-ietf-clue-rtp-mapping-00.txt > >> >> Pages : 19 > >> >> Date : 2013-02-17 > >> >> > >> >> Abstract: > >> >> This document describes mechanisms and recommended practice for > >> >> mapping RTP media streams defined in SDP to CLUE media captures. > >> >> > >> >> > >> >> The IETF datatracker status page for this draft is: > >> >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping > >> >> > >> >> There's also a htmlized version available at: > >> >> http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-00 > >> >> > >> >> > >> >> Internet-Drafts are also available by anonymous FTP at: > >> >> ftp://ftp.ietf.org/internet-drafts/ > >> >> > >> >> _______________________________________________ > >> >> 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 ietf@meetecho.com Thu Mar 14 12:42:38 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 7737811E821C for ; Thu, 14 Mar 2013 12:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.881 X-Spam-Level: * X-Spam-Status: No, score=1.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VfUZfKC-m9e for ; Thu, 14 Mar 2013 12:42:37 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg4.aruba.it [62.149.158.234]) by ietfa.amsl.com (Postfix) with ESMTP id 1409211E820F for ; Thu, 14 Mar 2013 12:42:36 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd04.ad.aruba.it with bizsmtp id BXiY1l00E2w8SR601XiaAc; Thu, 14 Mar 2013 20:42:35 +0100 Date: Thu, 14 Mar 2013 15:42:30 -0400 (EDT) From: Meetecho Team To: clue@ietf.org Message-ID: <860069.1.1363290150060.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363290150017" Subject: [clue] CLUE session recording available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:42:38 -0000 ------=_Part_0_2614099.1363290150017 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the CLUE WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#CLUE In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_2614099.1363290150017-- From mary.ietf.barnes@gmail.com Fri Mar 15 08:10: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 5F8E421F85EE for ; Fri, 15 Mar 2013 08:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.714 X-Spam-Level: X-Spam-Status: No, score=-102.714 tagged_above=-999 required=5 tests=[AWL=0.885, 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 Sbv70G9qqeSk for ; Fri, 15 Mar 2013 08:10:03 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 90AE221F8820 for ; Fri, 15 Mar 2013 08:10:02 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 9so1937928qea.21 for ; Fri, 15 Mar 2013 08:10:02 -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 :content-type; bh=yXtjV7y4MxfbG6D6GzirTOHO7SxflbXiunScO+n7lZQ=; b=0VTWvjTsroF4bZN5Fe3oLEGga66jZZjLONRob0crnMugAec+10yPOYTmVUTOtCqUkW uKfkTHWVBsSybeAax+lyGC8KMvnEkuts0S3KXNprG6ocwmEEDIJQu82eWGHmW1PMPmQi TpXCVLjZFoCgSvFDzeob0r9qGDEb2Dgy7qHtZ8YXZ9k4wcOnMrzy82lXIRKVloa4JuPQ mLKpy8JJ7Jar/llUC7y9KWAdJ40S3+kqTMceeSFdV+FS9MMYcad6Kg7UHKOVMCXQKpIi 3NcbB/XBoKpj9iV25P1kqDKhcdZP1ZerNdnA4fftNq7X9YohXRtEs/DvoYf3gaDSjaTN 414w== MIME-Version: 1.0 X-Received: by 10.49.85.34 with SMTP id e2mr6467503qez.1.1363360202035; Fri, 15 Mar 2013 08:10:02 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Fri, 15 Mar 2013 08:10:01 -0700 (PDT) Date: Fri, 15 Mar 2013 10:10:01 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] RTCWEB 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: Fri, 15 Mar 2013 15:10:04 -0000 For the folks that are in the MMUSIC WG session (listening to Cullen's proposals), ISTM that Plan B is much better for CLUE. What do others think? Mary. From pkyzivat@alum.mit.edu Fri Mar 15 09:35:24 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 2471D21F8788 for ; Fri, 15 Mar 2013 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=1.299, 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 p3byo3UrPITf for ; Fri, 15 Mar 2013 09:35:22 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 248E921F85BF for ; Fri, 15 Mar 2013 09:35:21 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id BotX1l0051afHeLA3sbKXl; Fri, 15 Mar 2013 16:35:19 +0000 Received: from dhcp-11c0.meeting.ietf.org ([IPv6:2001:df8:0:16:8120:584b:497a:1646]) by omta17.emeryville.ca.mail.comcast.net with comcast id BsbJ1l0051w3SQ48dsbJVC; Fri, 15 Mar 2013 16:35:18 +0000 Message-ID: <51434DC6.6090603@alum.mit.edu> Date: Sat, 16 Mar 2013 00:35:18 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1363365319; bh=cz/+7pyqkFNxOLo3pUt1+9RZJP8w71Cv68KOv5AZxfE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=a9ejfCvZ/eOVUQh98+075Iu5onNt+kW/hbwbsc42BM3FFUZoC2Q0+qwds2KVrADUy gTliSS2DmxWt/nAstWN9mQ/DKQ928U6McADPfePhIzM/llotgseyzP4gNZh3MaTcss XwYTNj/JdYDSfpzvWiVUG613II6PVIJpw0DK8AoBGDH6dzSKytKz9TRJX1E1dfFXb1 myv7QseIziesOS4lxJfHHFJbxSYrogMQK2vZIR/LNzU+4cTAYDuimZY53MZKeUgoCn JBaS8bLdfbTpHL9ryBzbzhgu8kwBedXbhEvOcnyXxusX4cvPs/XYPnRsvKwc/Pepzq NLE+EnSjNDCMQ== Subject: Re: [clue] RTCWEB 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: Fri, 15 Mar 2013 16:35:24 -0000 On 3/15/13 11:10 PM, Mary Barnes wrote: > For the folks that are in the MMUSIC WG session (listening to Cullen's > proposals), ISTM that Plan B is much better for CLUE. What do others > think? I still can't tell. Thanks, Paul From jonathan@vidyo.com Fri Mar 15 09:38:34 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 30CBB21F87FB for ; Fri, 15 Mar 2013 09:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=0.341, 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 g-CiW43mxW5Z for ; Fri, 15 Mar 2013 09:38:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6221F8801 for ; Fri, 15 Mar 2013 09:38:30 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CEACC8BE400 for ; Fri, 15 Mar 2013 12:38:29 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 622718BE7F2 for ; Fri, 15 Mar 2013 12:38:29 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Fri, 15 Mar 2013 12:37:58 -0400 From: Jonathan Lennox To: Mary Barnes Date: Fri, 15 Mar 2013 12:38:32 -0400 Thread-Topic: [clue] RTCWEB plan Thread-Index: Ac4hm3+W3uji8rzMSzOPtZNoFSkk5g== Message-ID: <83D9D707-10DA-4174-9817-70067AD189D7@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] RTCWEB 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: Fri, 15 Mar 2013 16:38:35 -0000 On Mar 15, 2013, at 11:10 AM, Mary Barnes wrote: > For the folks that are in the MMUSIC WG session (listening to Cullen's > proposals), ISTM that Plan B is much better for CLUE. What do others > think? >=20 > Mary. As an author of one of the drafts that's a major part of Plan B, I certainl= y prefer it. That said, I feel like the two mechanisms are increasingly becoming semanti= cally equivalent, as they strive to cover each others' requirements. At th= is point, I think we (or the plans' proponents) need to figure out where th= e plans actually differ substantively, other than in how things are actuall= y encoded into the SDP, so we can figure out which would work better for CL= UE.=20 -- Jonathan Lennox jonathan@vidyo.com From Christian.Groves@nteczone.com Sun Mar 17 17:22:11 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 0CDFF21F8BA1 for ; Sun, 17 Mar 2013 17:22:11 -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 AR6J7X+Q9SBA for ; Sun, 17 Mar 2013 17:22:10 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 24E9721F8BB6 for ; Sun, 17 Mar 2013 17:22:08 -0700 (PDT) Received: from ppp118-209-86-79.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.86.79]) by ipmail04.adl6.internode.on.net with ESMTP; 18 Mar 2013 10:51:52 +1030 Message-ID: <51465E1E.403@nteczone.com> Date: Mon, 18 Mar 2013 11:21:50 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Area of scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 00:22:11 -0000 Hello I just watched the meetecho CLUE WG discussion on the "area of scene". I think there was some confusion about that the 4 values represented a plane. I think the original intention of adding this was that it represented the "room" volume rather than a single plane. The reason for this attribute was to be able to determine how the various capture areas related to the overall room space. It would also give some idea of scale of the room. Regards, Christian From john@jlc.net Mon Mar 18 05:15:12 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 8829F21F8D29 for ; Mon, 18 Mar 2013 05:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knn5vFxYFwa9 for ; Mon, 18 Mar 2013 05:15:12 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id F405221F8D26 for ; Mon, 18 Mar 2013 05:15:11 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id C28E133C26; Mon, 18 Mar 2013 08:15:11 -0400 (EDT) Date: Mon, 18 Mar 2013 08:15:11 -0400 From: John Leslie To: Christian Groves Message-ID: <20130318121511.GB9569@verdi> References: <51465E1E.403@nteczone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51465E1E.403@nteczone.com> User-Agent: Mutt/1.4.1i Cc: "clue@ietf.org" Subject: Re: [clue] Area of scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 12:15:12 -0000 Christian Groves wrote: > > I think there was some confusion about that the 4 values represented a > plane. I would agree -- at least _some_ confusion... > I think the original intention of adding this was that it represented > the "room" volume rather than a single plane. Obviously, "area of scene" is a poor name for a representation of a room's volume. Possibly there was an intent for it to describe the floor area; or possibly it was mostly hand-waving... > The reason for this attribute was to be able to determine how the > various capture areas related to the overall room space. I will admit to being confused how it could do that. > It would also give some idea of scale of the room. Scale of the room would be "nice to know" but I'm not sure it's actually all that useful. It really doesn't buy much for video; and I suspect that for audio, deriving the impulse response would work much better. -- John Leslie From pkyzivat@alum.mit.edu Mon Mar 18 06:54:30 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 5EDCE21F8D61 for ; Mon, 18 Mar 2013 06:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 DzztyV363W7f for ; Mon, 18 Mar 2013 06:54:29 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 916A921F8D86 for ; Mon, 18 Mar 2013 06:54:28 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta13.westchester.pa.mail.comcast.net with comcast id D0St1l0070SCNGk5D1uTeD; Mon, 18 Mar 2013 13:54:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id D1uT1l0013ZTu2S3V1uT7f; Mon, 18 Mar 2013 13:54:27 +0000 Message-ID: <51471C4C.2090801@alum.mit.edu> Date: Mon, 18 Mar 2013 21:53:16 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: clue@ietf.org References: <51465E1E.403@nteczone.com> In-Reply-To: <51465E1E.403@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=1363614867; bh=FzEJLfli24Js5VVRibzMMRX0KeYvcw6v0jvfdLZNwD0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FXhF+D04C33O/sEvUZRzl5UeMLRxuB4v8mnf0wPTwnhqQBomWhGwCkzasYS/Hv1vC 6nyXhPuLtdiEL3QJxU0Z6xl5eQAQJ1EcmeQFay0/Rbms61aaNUjgFm4Njw4cF1TuAh 0TJh5vD12G0jqroNzDxp+cSmffhVQGAvHYcCye0aMgj4BcMCHL///T9Qd2MTrxqvLP qXHbUiAtV1EpN3blYf9WWycuJnz3c88pLWFtbBbez8VWr7C7Il6SwCrdhcrl2pN/EA +hJj5/UKYju/ZCyGfnbbligTjf5AqYe94NjvG5DJqfOg24jR+/yuhiDKCGFDcB8bnW kz5mY2EbvcsmA== Subject: Re: [clue] Area of scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:54:30 -0000 Christian, My point in raising the issue was that a planar "area of scene" is nonsense when the captures may be arbitrarily arranged in 3-space. As I understood the conversation, the general sense was that nobody had a compelling need for a "volume of capture", and so its easier just to omit this entirely. Certainly it can be added in later if some significant need is identified. Omitting it allows us to avoid some rat holes, such as what is a sufficient representation of the volume. Thanks, Paul On 3/18/13 8:21 AM, Christian Groves wrote: > Hello > > I just watched the meetecho CLUE WG discussion on the "area of scene". > > I think there was some confusion about that the 4 values represented a > plane. I think the original intention of adding this was that it > represented the "room" volume rather than a single plane. > > The reason for this attribute was to be able to determine how the > various capture areas related to the overall room space. It would also > give some idea of scale of the room. > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Mar 18 07:56:01 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 696F921F8F1E for ; Mon, 18 Mar 2013 07:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=0.775, 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 MB2wu0OGmLdZ for ; Mon, 18 Mar 2013 07:56:01 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id B536921F8F16 for ; Mon, 18 Mar 2013 07:56:00 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id cr7so1733468qab.15 for ; Mon, 18 Mar 2013 07:56:00 -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=fXNpsFIjrltvnObt5h0t/zEfDTWXQ4+PDDOopGjh2v0=; b=e9REE9dqHUFldkFufPTpLVHAFLqNOHZo9YZjX/bovo4u5DPdetW88wH8YUkb2vl46f 17Eam0/Ew1itTdJmGzX+/zpvZdQjdYQv2AUjWNvQIth+B140zMFMcZYhU8fTJCXs4Q6D ztbSMcdNLI2ZqAGH12cMxrf5Qwv+zRqm5xEWMX+crmuECrPDeRglBwgbLVUHhgacDgDR Bc3QuhwA2lrDuNGjglDMk32h7Q57jVvvFQHCtcfrseoPhFBoPHoEiYFT/usf4mcvMFNy 1dpCbLRXDL/mYaO1shA1nZLY2g1ixK2fKf1BmCgBYlmRPt3WZuq3ITHdUdO2w+OuxwMP agAg== MIME-Version: 1.0 X-Received: by 10.224.216.65 with SMTP id hh1mr19914853qab.43.1363618560126; Mon, 18 Mar 2013 07:56:00 -0700 (PDT) Received: by 10.49.24.130 with HTTP; Mon, 18 Mar 2013 07:56:00 -0700 (PDT) Date: Mon, 18 Mar 2013 09:56:00 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] No Design team call today - March 18, 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: Mon, 18 Mar 2013 14:56:01 -0000 For obvious reasons. From pkyzivat@alum.mit.edu Mon Mar 18 09:10: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 02B3221F8DD1 for ; Mon, 18 Mar 2013 09:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 glnee5UY9woU for ; Mon, 18 Mar 2013 09:10:42 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 2422621F8DD9 for ; Mon, 18 Mar 2013 09:10:42 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta05.westchester.pa.mail.comcast.net with comcast id D1Tc1l0080mv7h0554AhHD; Mon, 18 Mar 2013 16:10:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id D4Ah1l00H3ZTu2S3X4AhHi; Mon, 18 Mar 2013 16:10:41 +0000 Message-ID: <51473C80.8000205@alum.mit.edu> Date: Tue, 19 Mar 2013 00:10:40 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: CLUE References: <20130318153818.11829.31510.idtracker@ietfa.amsl.com> In-Reply-To: <20130318153818.11829.31510.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130318153818.11829.31510.idtracker@ietfa.amsl.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=1363623041; bh=qPvOx9TOuWzoWwj+n0b0bt/dBV62qc0Z9k0skNhPfb4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZitlJELNYYgkMnsF/kxpm6oR+YerFGWAdWv3R9PeHK07Gx/PuqqPS+GbRrXY3xAyR zmRVCnH6OIY4RWDShLKWyAlWLy6mW519qZAM+vw3q5iETvtFsLtRBR+fBQq9OaN+X2 DYuIo5EUyIeX6i1K1kIj8S2YhhTdetqBOamHK4VJm5Q0W0cYkZsbUzuc2e27JFz7KN IS/Ul8JaLixx7Rx7RebyeK52CUNlyuyCOzU9956C6/eFXSxs6MBs7KwF5vRrcT67zL hfMSTpdvu7JqU1glXb0kTMCWVeJDzWDtLThYNQ9yFNacEhUWLAtgrcg5FWyCymB+Ey nM6RinKEzSoiQ== Subject: [clue] New Version Notification for draft-kyzivat-clue-telemedical-callflow-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:10:43 -0000 I just refreshed this draft so it won't expire. There are no content changes in it. Clearly it is out of date and will need to be updated once we have nailed down some of the signaling. Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-clue-telemedical-callflow-02.txt Date: Mon, 18 Mar 2013 08:38:18 -0700 From: internet-drafts@ietf.org To: pkyzivat@alum.mit.edu A new version of I-D, draft-kyzivat-clue-telemedical-callflow-02.txt has been successfully submitted by Paul H. Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-clue-telemedical-callflow Revision: 02 Title: CLUE Telemedical Use Case Callflow Creation date: 2013-03-18 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-telemedical-callflow-02.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-telemedical-callflow Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-telemedical-callflow-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-telemedical-callflow-02 Abstract: This is the beginning of an example call flow for an instantiation of the use case described in the telemedical use case [I-D.xiao-clue-telemedical-use-case]. More detail will be added later. The IETF Secretariat From eckelcu@cisco.com Tue Mar 19 10:30:49 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 467A821F8F2F for ; Tue, 19 Mar 2013 10:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ai6FwV00CBqq for ; Tue, 19 Mar 2013 10:30:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80421F8F22 for ; Tue, 19 Mar 2013 10:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1618; q=dns/txt; s=iport; t=1363714248; x=1364923848; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=sCQrFMvf3tr7AKxXCQON6zBYSwYjUi1au4yBAdceqAw=; b=WEusQHIN609zQOlGqB0ZFWeYcfXn1nMYcxURiMJdZ6YGm864Pjke1XCB odNQIBEbnIaZSQING0aNJZTKwjdsVcBmk391QqZTHXSp745vSYk6xAayK j57aYi4XtI2nYf+pXiy0e8Ox8cTgTIBVg7OYnCPKjFmP5dYhXcoZ7WSdG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIOgSFGtJXG9/2dsb2JhbABDxRuBWhZtB4ImAQQ6UQEqFEImAQQbiAsBoHqRFZAbjl2DF2EDp2GDCoFqBzc X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="189166758" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2013 17:30:48 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2JHUl95019704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Mar 2013 17:30:47 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.144]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 12:30:47 -0500 From: "Charles Eckel (eckelcu)" To: "clue@ietf.org" Thread-Topic: comments on draft-kyzivat-clue-signaling-02 Thread-Index: Ac4kx26IcGghq3cxS5yIrfumlo41CQ== Date: Tue, 19 Mar 2013 17:30:46 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828047D8A81@xmb-aln-x08.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.16.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] comments on draft-kyzivat-clue-signaling-02 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, 19 Mar 2013 17:30:49 -0000 Hi Paul, I mentioned some of these at the mic, at which time I agreed to follow up = on them via the list.=20 1) Section 3.1.3. It seems natural and appropriate to negotiate the CLUE version in SDP where= you negotiate the CLUE channel. This is essentially what we have proposed = to do for BFCPBIS as well. 2) Section 3.3.2 The section is titled "Piggybacking ACK on Requests", yet it contains the f= ollowing bullet: o If a valid message is received and there is no need to immediately send another message, then a NO-OP message is sent to acknowledge the received message. But a NO-OP message is never sent in response to a NO-OP message. It seems to me that this results in it being essentially the same as the ex= plicit ACK method in section 3.3.1. If we were to omit this bullet, then I = see some benefit in the Piggybacking method. Do you see any problems that n= ecessitate a NO-OP? 3) Section 3.4.1 reads as follows: If the change must be outside the range of what was advertised, then the provider must cease transmitting the capture encoding. It then must send a new ADVERTISEMENT reflecting what it is now capable of delivering. I assume congestion resulting in tmmbr would NOT require a new advertisemen= t. Is that consistent with your thinking on this? 4) Section 3.4.2 Handling loss of CLUE state information by establishing a new CLUE session = seems simply and sufficient.=20 5) Section 4 and 5 seem to be good places to insert the information in draf= t-hansen-clue-sdp-interaction. Cheers, Charles From Christian.Groves@nteczone.com Sun Mar 24 20:46: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 1D09A21F8E57 for ; Sun, 24 Mar 2013 20:46:07 -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 VG2AhrxLxeN8 for ; Sun, 24 Mar 2013 20:46:06 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB0D21F8E56 for ; Sun, 24 Mar 2013 20:46:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAE7HT1F20Q8w/2dsb2JhbAANNsVighODGAEBAQQBAQE1GxsKEQsYCRYPCQMCAQIBFTATBgIBAYgcrwOSRwSPHxaDKgOrCQ Received: from ppp118-209-15-48.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.15.48]) by ipmail04.adl6.internode.on.net with ESMTP; 25 Mar 2013 14:16:04 +1030 Message-ID: <514FC87C.9030607@nteczone.com> Date: Mon, 25 Mar 2013 14:46:04 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <51465E1E.403@nteczone.com> <51471C4C.2090801@alum.mit.edu> In-Reply-To: <51471C4C.2090801@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Area of scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 03:46:07 -0000 Hello Paul, Yes I agree planar "area of scene" is nonsense. Another thing it could be used for perhaps is to get a sense of the acoustics of the room? i.e. an auditorium sized area versus a meeting room I agree that setting a volume based on 4 point may be hard if you have a curved room :-). Regards, Christian On 19/03/2013 12:53 AM, Paul Kyzivat wrote: > Christian, > > My point in raising the issue was that a planar "area of scene" is > nonsense when the captures may be arbitrarily arranged in 3-space. > > As I understood the conversation, the general sense was that nobody > had a compelling need for a "volume of capture", and so its easier > just to omit this entirely. Certainly it can be added in later if some > significant need is identified. Omitting it allows us to avoid some > rat holes, such as what is a sufficient representation of the volume. > > Thanks, > Paul > > On 3/18/13 8:21 AM, Christian Groves wrote: >> Hello >> >> I just watched the meetecho CLUE WG discussion on the "area of scene". >> >> I think there was some confusion about that the 4 values represented a >> plane. I think the original intention of adding this was that it >> represented the "room" volume rather than a single plane. >> >> The reason for this attribute was to be able to determine how the >> various capture areas related to the overall room space. It would also >> give some idea of scale of the room. >> >> Regards, Christian >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Sun Mar 24 20:57: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 2779521F8C49 for ; Sun, 24 Mar 2013 20:57:03 -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 sMZBc9Gn4aaq for ; Sun, 24 Mar 2013 20:57:02 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 4E62321F8C00 for ; Sun, 24 Mar 2013 20:57:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBADjKT1F20Q8w/2dsb2JhbAANNcVighODGAEBAQQBAQE1GxsKEQsYCRYPCQMCAQIBFTATBgIBAYgcrwaSSQSPHxaDKgOrCYFWBw Received: from ppp118-209-15-48.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.15.48]) by ipmail04.adl6.internode.on.net with ESMTP; 25 Mar 2013 14:26:58 +1030 Message-ID: <514FCB08.4050501@nteczone.com> Date: Mon, 25 Mar 2013 14:56:56 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <92B7E61ADAC1BB4F941F943788C08828047D8A81@xmb-aln-x08.cisco.com> In-Reply-To: <92B7E61ADAC1BB4F941F943788C08828047D8A81@xmb-aln-x08.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] comments on draft-kyzivat-clue-signaling-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 03:57:03 -0000 Hello, Please see my comments below. On 20/03/2013 4:30 AM, Charles Eckel (eckelcu) wrote: > Hi Paul, > > I mentioned some of these at the mic, at which time I agreed to follow up on them via the list. > > 1) Section 3.1.3. > It seems natural and appropriate to negotiate the CLUE version in SDP where you negotiate the CLUE channel. This is essentially what we have proposed to do for BFCPBIS as well. [CNG] I would agree but I think you'd also want to carry the indication of the agreed version in CLUE so the endpoints know exactly what version is being used. > > 2) Section 3.3.2 > The section is titled "Piggybacking ACK on Requests", yet it contains the following bullet: > o If a valid message is received and there is no need to immediately > send another message, then a NO-OP message is sent to acknowledge > the received message. But a NO-OP message is never sent in > response to a NO-OP message. > It seems to me that this results in it being essentially the same as the explicit ACK method in section 3.3.1. If we were to omit this bullet, then I see some benefit in the Piggybacking method. Do you see any problems that necessitate a NO-OP? > > 3) Section 3.4.1 reads as follows: > > If the change must be outside the range of what was advertised, > then the provider must cease transmitting the capture encoding. > It then must send a new ADVERTISEMENT reflecting what it is now > capable of delivering. > > I assume congestion resulting in tmmbr would NOT require a new advertisement. Is that consistent with your thinking on this? > > 4) Section 3.4.2 > Handling loss of CLUE state information by establishing a new CLUE session seems simply and sufficient. [CNG] This would require a new O/A and re-establishment of the transport session. This would require synchronisation with ongoing RTP streams as they most likely will be associated with particular capture IDs etc. If there's nothing wrong with the transport the Consumer could as easily send a Configure message with a code indicating "please send an updated advertisement". > > 5) Section 4 and 5 seem to be good places to insert the information in draft-hansen-clue-sdp-interaction. > > Cheers, > Charles > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Mar 25 06:51:32 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 0135021F8CF7 for ; Mon, 25 Mar 2013 06:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[BAYES_50=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 3Org8H5ys6fp for ; Mon, 25 Mar 2013 06:51:31 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8B821F8CF5 for ; Mon, 25 Mar 2013 06:51:27 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id b12so1778963qca.32 for ; Mon, 25 Mar 2013 06:51:26 -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 :content-type; bh=022xgpTIL36vbrE4PLYl/B+vL7mPbqDz1QqWYqLZ+9Q=; b=ZB855gLAGYVcagTMCM+esIpkPGj2p23wWGaIKpVSCNUO8dUr6tG2L8nFivRj7UeofK amV5EIWSuPyc04n3sAPYZyFsPRky58LIV2VCCgVjA9+sEe6e7g1dASSKMWZrJAArafGr nHz0tq/Eg8udpIBAfebar5dYJSo2Rf5OrMN1d3Lw7jC+xGoYtzOxyPWKgyW09STpQPJ5 Bnq1WrV0Ocy1TXUSClSrsQVx72JBrtb4VRb9Eb2B4rFAyPg0jCGagH4GUzm+kbl9/Aks GzdY0uEQNQMRxMBGS5pnE+aWLoNUw9S5jv7/Y4C1HgM7ygzRteQNHXLhw/lgepMaQ1Cc x8jQ== MIME-Version: 1.0 X-Received: by 10.49.87.40 with SMTP id u8mr4215821qez.62.1364219485975; Mon, 25 Mar 2013 06:51:25 -0700 (PDT) Received: by 10.49.94.166 with HTTP; Mon, 25 Mar 2013 06:51:25 -0700 (PDT) Date: Mon, 25 Mar 2013 08:51:25 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] No CLUE Meeting Today: Monday, March 25th, 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: Mon, 25 Mar 2013 13:51:32 -0000 Mary. From pkyzivat@alum.mit.edu Mon Mar 25 07:24: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 EC22721F8DDA for ; Mon, 25 Mar 2013 07:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[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 PsSgVOXrNxJJ for ; Mon, 25 Mar 2013 07:24:15 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE2121F8CB0 for ; Mon, 25 Mar 2013 07:24:10 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta03.westchester.pa.mail.comcast.net with comcast id FmcK1l0051swQuc53qQAHk; Mon, 25 Mar 2013 14:24:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id FqQ91l00V3ZTu2S3bqQ98U; Mon, 25 Mar 2013 14:24:10 +0000 Message-ID: <51505E09.4050400@alum.mit.edu> Date: Mon, 25 Mar 2013 22:24:09 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <92B7E61ADAC1BB4F941F943788C08828047D8A81@xmb-aln-x08.cisco.com> <514FCB08.4050501@nteczone.com> In-Reply-To: <514FCB08.4050501@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=1364221450; bh=zvVooZyX1uPThS7vq5l1eitEWkmpy6rrthW970EKyWY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HiPpTx3tMRHRTU1q5rESS7WT0s5/jrkX7vpX45TBZXe29BZ5VwyMt5mTHgyJOWaKc I/WT1+l2OoXEHW4MhrYJ1DQM8hM6KkILwo/jhWXh4lCmyUcFaGZ/wZe0d6bfcSpdby nhcVul9IyHAR2mR+jC5qIXhdtCkzlYHuoI7IUGqTnIBNEFKxF1MDSKH5nMsvip5Q+G S50ZHYagCclHnMUHub+VmcBo4x9oFs5HePLdffSTztdElcyl626pU9BkE5CDqwbzki VOsPMGu48NakhoionWW/ubRU8x5nLGb5Pt8guQP/8YXR0V/nv/zu3PpilEnwqxz76o iA2v0kHRWL5Sw== Subject: Re: [clue] comments on draft-kyzivat-clue-signaling-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 14:24:16 -0000 Some followup inline. On 3/25/13 11:56 AM, Christian Groves wrote: >> 1) Section 3.1.3. >> It seems natural and appropriate to negotiate the CLUE version in SDP >> where you negotiate the CLUE channel. This is essentially what we have >> proposed to do for BFCPBIS as well. > [CNG] I would agree but I think you'd also want to carry the indication > of the agreed version in CLUE so the endpoints know exactly what version > is being used. If we negotiate it in SDP but also signal it in the clue channel itself, then we introduce the possibility of a new class of errors when these values are inconsistent. That isn't a fatal flaw, but it is worth considering. If it is to be signaled in the clue channel, then why not verify/negotiate it there as well, rather than in SDP? A downside of that is that the sip session may get set up before discovering that the two sides don't support a common clue version. But that is only a problem if it then leads to dropping the call. I think in reality that would lead to treating it as a "legacy" call. I guess an advantage to having the version in SDP is that it might be used to make a routing decision, to an endpoint that supports that version, rather than a different endpoint that doesn't. But I find this rather far fetched. So, ISTM that if we are to convey the version in the clue channel we might as well do the version negotiation there too. That would keep things quite modular. But I can be convinced otherwise. >> 4) Section 3.4.2 >> Handling loss of CLUE state information by establishing a new CLUE >> session seems simply and sufficient. > [CNG] This would require a new O/A and re-establishment of the transport > session. This may require some discussion and eventually documentation. Presumably a new O/A will be required if any part of the SCTP association addresses must be changed. I don't know if there is any point in attempting to reestablish the association using the same address info. (IIUC, SCTP supports multiple, alternative, addresses for each end of the association, and even adding new ones in band in the protocol. But the SCTP over DTLS mapping takes that away. So presumably we can ignore it.) If a new O/A is done to "fix" this, must any special behavior be called out to ensure the exact same 5-tuple isn't attempted again? There may be no alternative to the local address, though a new port may be possible. If ICE is in use, then perhaps candidate gathering could be restarted. > This would require synchronisation with ongoing RTP streams as > they most likely will be associated with particular capture IDs etc. I guess this depends on some local implementation issues that we have no business specifying. If capture IDs are assigned in some deterministic way then maybe they will be stable across a reset. But if they are dynamically assigned then they probably won't be. So does this mean that RTP should cease, or revert to "legacy mode", until the clue channel is renegotiated? Or can RTP simply continue as it was until a new advertisement/config demands that it change? > If there's nothing wrong with the transport the Consumer could as easily > send a Configure message with a code indicating "please send an updated > advertisement". Maybe. IMO this calls for some state machine work that can be used to identify significant states. Then behavior can be linked to the state. Thanks, Paul From Mark.Duckworth@polycom.com Mon Mar 25 08:53:32 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 1278B21F8F24 for ; Mon, 25 Mar 2013 08:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 ZE4ClWx+GfPs for ; Mon, 25 Mar 2013 08:53:28 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7193511E80B8 for ; Mon, 25 Mar 2013 08:53:24 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::5efe:10.236.0.200]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 25 Mar 2013 08:51:52 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 25 Mar 2013 08:53:21 -0700 Thread-Topic: [clue] Area of scene Thread-Index: Ac4pCxUX2pJtBm7TQwqSZ7zSjmr3RAAZOBJw Message-ID: <9C23AB934B394845A7B228239B6EAF41B58B3E@CRPMBOXPRD01.polycom.com> References: <51465E1E.403@nteczone.com> <51471C4C.2090801@alum.mit.edu> <514FC87C.9030607@nteczone.com> In-Reply-To: <514FC87C.9030607@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] Area of scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 15:53:33 -0000 I agree with Paul - "the general sense was that nobody had a compelling nee= d for a "volume of capture", and so it's easier just to omit this entirely"= . I propose we remove it from the framework and data model. I looked for the history of why "Area of Scene" was added in the first plac= e, but I can't find any documentation of why we added it. It first appeare= d in draft-ietf-clue-framework-01, which was shortly after the October 2011= interim meeting in Andover. I couldn't find anything in the interim meeti= ng notes or on the email list about why we added it. It seems to me there is nothing in the use cases or requirements documents = that would require this area (or volume) of scene attribute, so removing it= to simplify things seems like a good idea. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: Sunday, March 24, 2013 11:46 PM > To: clue@ietf.org > Subject: Re: [clue] Area of scene >=20 > Hello Paul, >=20 > Yes I agree planar "area of scene" is nonsense. >=20 > Another thing it could be used for perhaps is to get a sense of the acous= tics > of the room? i.e. an auditorium sized area versus a meeting room >=20 > I agree that setting a volume based on 4 point may be hard if you have a > curved room :-). >=20 > Regards, Christian >=20 > On 19/03/2013 12:53 AM, Paul Kyzivat wrote: > > Christian, > > > > My point in raising the issue was that a planar "area of scene" is > > nonsense when the captures may be arbitrarily arranged in 3-space. > > > > As I understood the conversation, the general sense was that nobody > > had a compelling need for a "volume of capture", and so its easier > > just to omit this entirely. Certainly it can be added in later if some > > significant need is identified. Omitting it allows us to avoid some > > rat holes, such as what is a sufficient representation of the volume. > > > > Thanks, > > Paul > > > > On 3/18/13 8:21 AM, Christian Groves wrote: > >> Hello > >> > >> I just watched the meetecho CLUE WG discussion on the "area of scene". > >> > >> I think there was some confusion about that the 4 values represented > >> a plane. I think the original intention of adding this was that it > >> represented the "room" volume rather than a single plane. > >> > >> The reason for this attribute was to be able to determine how the > >> various capture areas related to the overall room space. It would > >> also give some idea of scale of the room. > >> > >> Regards, Christian > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Mar 25 16:47: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 BDBDF21F87D1 for ; Mon, 25 Mar 2013 16:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[AWL=1.600, 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 dFQvIdMAZBuh for ; Mon, 25 Mar 2013 16:47:35 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id C093221F87A4 for ; Mon, 25 Mar 2013 16:47:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPfgUFF20Spw/2dsb2JhbAANNsN2gSCDEwEBAQQBAQE1GxsKDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiByvJIMxkAUEjViBNRIGgzoDqwmBXw Received: from ppp118-209-42-112.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.42.112]) by ipmail06.adl2.internode.on.net with ESMTP; 26 Mar 2013 10:17:33 +1030 Message-ID: <5150E212.3030808@nteczone.com> Date: Tue, 26 Mar 2013 10:47:30 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <51465E1E.403@nteczone.com> <51471C4C.2090801@alum.mit.edu> <514FC87C.9030607@nteczone.com> <9C23AB934B394845A7B228239B6EAF41B58B3E@CRPMBOXPRD01.polycom.com> In-Reply-To: <9C23AB934B394845A7B228239B6EAF41B58B3E@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Area of scene X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 23:47:37 -0000 Hello Mark, I had a look also, I couldn't find anything either. I don't have any objection to remove it if no one is planning on using it. Christian On 26/03/2013 2:53 AM, Duckworth, Mark wrote: > I agree with Paul - "the general sense was that nobody had a compelling need for a "volume of capture", and so it's easier just to omit this entirely". I propose we remove it from the framework and data model. > > I looked for the history of why "Area of Scene" was added in the first place, but I can't find any documentation of why we added it. It first appeared in draft-ietf-clue-framework-01, which was shortly after the October 2011 interim meeting in Andover. I couldn't find anything in the interim meeting notes or on the email list about why we added it. > > It seems to me there is nothing in the use cases or requirements documents that would require this area (or volume) of scene attribute, so removing it to simplify things seems like a good idea. > > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: Sunday, March 24, 2013 11:46 PM >> To: clue@ietf.org >> Subject: Re: [clue] Area of scene >> >> Hello Paul, >> >> Yes I agree planar "area of scene" is nonsense. >> >> Another thing it could be used for perhaps is to get a sense of the acoustics >> of the room? i.e. an auditorium sized area versus a meeting room >> >> I agree that setting a volume based on 4 point may be hard if you have a >> curved room :-). >> >> Regards, Christian >> >> On 19/03/2013 12:53 AM, Paul Kyzivat wrote: >>> Christian, >>> >>> My point in raising the issue was that a planar "area of scene" is >>> nonsense when the captures may be arbitrarily arranged in 3-space. >>> >>> As I understood the conversation, the general sense was that nobody >>> had a compelling need for a "volume of capture", and so its easier >>> just to omit this entirely. Certainly it can be added in later if some >>> significant need is identified. Omitting it allows us to avoid some >>> rat holes, such as what is a sufficient representation of the volume. >>> >>> Thanks, >>> Paul >>> >>> On 3/18/13 8:21 AM, Christian Groves wrote: >>>> Hello >>>> >>>> I just watched the meetecho CLUE WG discussion on the "area of scene". >>>> >>>> I think there was some confusion about that the 4 values represented >>>> a plane. I think the original intention of adding this was that it >>>> represented the "room" volume rather than a single plane. >>>> >>>> The reason for this attribute was to be able to determine how the >>>> various capture areas related to the overall room space. It would >>>> also give some idea of scale of the room. >>>> >>>> Regards, Christian >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Mar 25 17:07:38 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 525CB21F86CD for ; Mon, 25 Mar 2013 17:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 Nn2HlHRmBQW4 for ; Mon, 25 Mar 2013 17:07:37 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id F0DBB21F86D9 for ; Mon, 25 Mar 2013 17:07:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPTkUFF20Spw/2dsb2JhbAANLArDdoEggxMBAQEDAQEBATUbFQYKEQsYCRYPCQMCAQIBFTATBgIBAYgKEq8fgzGQBgSNXoFBg0ADqwk Received: from ppp118-209-42-112.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.42.112]) by ipmail06.adl2.internode.on.net with ESMTP; 26 Mar 2013 10:37:36 +1030 Message-ID: <5150E6C5.5040109@nteczone.com> Date: Tue, 26 Mar 2013 11:07:33 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <92B7E61ADAC1BB4F941F943788C08828047D8A81@xmb-aln-x08.cisco.com> <514FCB08.4050501@nteczone.com> <51505E09.4050400@alum.mit.edu> In-Reply-To: <51505E09.4050400@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] comments on draft-kyzivat-clue-signaling-02 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, 26 Mar 2013 00:07:38 -0000 Hello Paul, Please see see below. Regards, Christian On 26/03/2013 1:24 AM, Paul Kyzivat wrote: > Some followup inline. > > On 3/25/13 11:56 AM, Christian Groves wrote: > >>> 1) Section 3.1.3. >>> It seems natural and appropriate to negotiate the CLUE version in SDP >>> where you negotiate the CLUE channel. This is essentially what we have >>> proposed to do for BFCPBIS as well. >> [CNG] I would agree but I think you'd also want to carry the indication >> of the agreed version in CLUE so the endpoints know exactly what version >> is being used. > > If we negotiate it in SDP but also signal it in the clue channel > itself, then we introduce the possibility of a new class of errors > when these values are inconsistent. That isn't a fatal flaw, but it is > worth considering. [CNG] I don't think it a flaw at all. If either case if you get an information element that is not relevant for the version supported its an error. > > If it is to be signaled in the clue channel, then why not > verify/negotiate it there as well, rather than in SDP? [CNG] It could be done but its potentially another round trip. > > A downside of that is that the sip session may get set up before > discovering that the two sides don't support a common clue version. > But that is only a problem if it then leads to dropping the call. I > think in reality that would lead to treating it as a "legacy" call. [CNG] Yes > > I guess an advantage to having the version in SDP is that it might be > used to make a routing decision, to an endpoint that supports that > version, rather than a different endpoint that doesn't. But I find > this rather far fetched. [CNG] The advantage is what is stated above. You can figure out the version before establishing another data connection. > > So, ISTM that if we are to convey the version in the clue channel we > might as well do the version negotiation there too. That would keep > things quite modular. > > But I can be convinced otherwise. > >>> 4) Section 3.4.2 >>> Handling loss of CLUE state information by establishing a new CLUE >>> session seems simply and sufficient. >> [CNG] This would require a new O/A and re-establishment of the transport >> session. > > This may require some discussion and eventually documentation. > Presumably a new O/A will be required if any part of the SCTP > association addresses must be changed. I don't know if there is any > point in attempting to reestablish the association using the same > address info. [CNG] I think it depends on the class of error as to whether the same 5 tuple is used. If there's a network problem probably not, if the endpoint SW has hung that tuple maybe its OK to restart it. > > (IIUC, SCTP supports multiple, alternative, addresses for each end of > the association, and even adding new ones in band in the protocol. But > the SCTP over DTLS mapping takes that away. So presumably we can > ignore it.) > > If a new O/A is done to "fix" this, must any special behavior be > called out to ensure the exact same 5-tuple isn't attempted again? > There may be no alternative to the local address, though a new port > may be possible. If ICE is in use, then perhaps candidate gathering > could be restarted. > >> This would require synchronisation with ongoing RTP streams as >> they most likely will be associated with particular capture IDs etc. > > I guess this depends on some local implementation issues that we have > no business specifying. If capture IDs are assigned in some > deterministic way then maybe they will be stable across a reset. But > if they are dynamically assigned then they probably won't be. [CNG] I don't think we need to specify CaptureID allocation. Rather to indicate what happens to existing captureIDs (particularly those assigned to an RTCP stream) when a CLUE association is removed (and possibly replaced). > > So does this mean that RTP should cease, or revert to "legacy mode", > until the clue channel is renegotiated? Or can RTP simply continue as > it was until a new advertisement/config demands that it change? [CNG] That's the question that needs consideration. We need to specify some common behaviour here. In some respects we need to consider CLUE captureID etc lifetime. I could envisage that a CLUE association is established to setup a conference and then removed once the conference has been established. So it seems that to continue RTP with whatever CLUE Ids that were negotiated before would be OK behaviour. However if a new CLUE association is started it would seem to me that any assumptions about state should be reset. > >> If there's nothing wrong with the transport the Consumer could as easily >> send a Configure message with a code indicating "please send an updated >> advertisement". > > Maybe. > > IMO this calls for some state machine work that can be used to > identify significant states. Then behavior can be linked to the state. [CNG] I'm not sure what you mean here? With the framework there's an assumption that the consumer maintains its configuration wrt to CLUE. If this changes or is lost then the consumer should be able to request an updated Advertisement. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Mar 26 09:18:13 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 88D0D21F8733 for ; Tue, 26 Mar 2013 09:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=0.300, 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 Ae8W1CLAtlIC for ; Tue, 26 Mar 2013 09:18:12 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1244F21F872E for ; Tue, 26 Mar 2013 09:18:10 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id GBaW1l00B1wpRvQ53GJ99Q; Tue, 26 Mar 2013 16:18:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:d4c9:483f:1fd1:f6e1]) by omta18.westchester.pa.mail.comcast.net with comcast id GGJ81l00E5QjTFu3eGJ8B7; Tue, 26 Mar 2013 16:18:09 +0000 Message-ID: <5151CA3F.5050607@alum.mit.edu> Date: Wed, 27 Mar 2013 00:18:07 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <92B7E61ADAC1BB4F941F943788C08828047D8A81@xmb-aln-x08.cisco.com> <514FCB08.4050501@nteczone.com> <51505E09.4050400@alum.mit.edu> <5150E6C5.5040109@nteczone.com> In-Reply-To: <5150E6C5.5040109@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=1364314690; bh=2kh2BOQF+32W2XZP3/tqpbIigIssxy7wuMLpZr4QQMw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=MIonPoL9IV9YEg5jbXfDnh/wr/xPuwktbJYb1TTpdKH5eZOlWKtM0Gy2DzZm/wgDE JE66vuNrQjr7rGVkwWGjUq/9UNkyQbXlnDd+rwGKhCzWl0JBPm2WL6uZPCbSKpNIsb gNxC/EBdMWutXRvlbuhKsdTv0pdqqkRKmb9/9DTF1uI0Kdl4fEAzFRnki8AYwbufLJ l+spKF2gU1h05BFlsJi5P5NwNLd2xJ/Ez0AsTu7D6c/ZoOiZ2SJV+JS6uUCyqEMauI E/XIMRQY5InatOnKM3SUFZMuuIsCj9OwoVNur1AYUDDAPDcQZZrBD/2bkKflicK15t /gdh7rW0voSHQ== Subject: Re: [clue] comments on draft-kyzivat-clue-signaling-02 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, 26 Mar 2013 16:18:13 -0000 More comments inline On 3/26/13 8:07 AM, Christian Groves wrote: > Hello Paul, > > Please see see below. > > Regards, Christian > > On 26/03/2013 1:24 AM, Paul Kyzivat wrote: >> Some followup inline. >> >> On 3/25/13 11:56 AM, Christian Groves wrote: >> >>>> 1) Section 3.1.3. >>>> It seems natural and appropriate to negotiate the CLUE version in SDP >>>> where you negotiate the CLUE channel. This is essentially what we have >>>> proposed to do for BFCPBIS as well. >>> [CNG] I would agree but I think you'd also want to carry the indication >>> of the agreed version in CLUE so the endpoints know exactly what version >>> is being used. >> >> If we negotiate it in SDP but also signal it in the clue channel >> itself, then we introduce the possibility of a new class of errors >> when these values are inconsistent. That isn't a fatal flaw, but it is >> worth considering. > [CNG] I don't think it a flaw at all. If either case if you get an > information element that is not relevant for the version supported its > an error. >> >> If it is to be signaled in the clue channel, then why not >> verify/negotiate it there as well, rather than in SDP? > [CNG] It could be done but its potentially another round trip. Maybe, depending on the details of how it is done. I agree that doing it in SDP (or in SIP) will guarantee the minimum time to get it worked out. I'm ok with doing it in SDP (or SIP) as long as we are satisfied with a negotiation that fits well in SDP O/A. Perhaps we should be talking about versioning the overall relationship between the two endpoints - encompassing all the signaling and coordinated clue-mandated behavior, whether in SIP, SDP, over the clue channel, in RTP, etc. We then might, or might not, want to separately negotiate a finer level of versioning of the clue channel as a sub-protocol of that. >> A downside of that is that the sip session may get set up before >> discovering that the two sides don't support a common clue version. >> But that is only a problem if it then leads to dropping the call. I >> think in reality that would lead to treating it as a "legacy" call. > [CNG] Yes >> >> I guess an advantage to having the version in SDP is that it might be >> used to make a routing decision, to an endpoint that supports that >> version, rather than a different endpoint that doesn't. But I find >> this rather far fetched. > [CNG] The advantage is what is stated above. You can figure out the > version before establishing another data connection. >> >> So, ISTM that if we are to convey the version in the clue channel we >> might as well do the version negotiation there too. That would keep >> things quite modular. >> >> But I can be convinced otherwise. >> >>>> 4) Section 3.4.2 >>>> Handling loss of CLUE state information by establishing a new CLUE >>>> session seems simply and sufficient. >>> [CNG] This would require a new O/A and re-establishment of the transport >>> session. >> >> This may require some discussion and eventually documentation. >> Presumably a new O/A will be required if any part of the SCTP >> association addresses must be changed. I don't know if there is any >> point in attempting to reestablish the association using the same >> address info. > [CNG] I think it depends on the class of error as to whether the same 5 > tuple is used. If there's a network problem probably not, if the > endpoint SW has hung that tuple maybe its OK to restart it. >> >> (IIUC, SCTP supports multiple, alternative, addresses for each end of >> the association, and even adding new ones in band in the protocol. But >> the SCTP over DTLS mapping takes that away. So presumably we can >> ignore it.) >> >> If a new O/A is done to "fix" this, must any special behavior be >> called out to ensure the exact same 5-tuple isn't attempted again? >> There may be no alternative to the local address, though a new port >> may be possible. If ICE is in use, then perhaps candidate gathering >> could be restarted. >> >>> This would require synchronisation with ongoing RTP streams as >>> they most likely will be associated with particular capture IDs etc. >> >> I guess this depends on some local implementation issues that we have >> no business specifying. If capture IDs are assigned in some >> deterministic way then maybe they will be stable across a reset. But >> if they are dynamically assigned then they probably won't be. > [CNG] I don't think we need to specify CaptureID allocation. Rather to > indicate what happens to existing captureIDs (particularly those > assigned to an RTCP stream) when a CLUE association is removed (and > possibly replaced). Yes. >> So does this mean that RTP should cease, or revert to "legacy mode", >> until the clue channel is renegotiated? Or can RTP simply continue as >> it was until a new advertisement/config demands that it change? > [CNG] That's the question that needs consideration. We need to specify > some common behaviour here. In some respects we need to consider CLUE > captureID etc lifetime. I have been assuming the lifetime is "until changed via a new advertisement". I think that is fine as long as the clue channel is present and operational. But I agree we have more to specify in the case where the clue channel is closed or becomes non-functional. > I could envisage that a CLUE association is > established to setup a conference and then removed once the conference > has been established. I had not considered that. It seems like a bad idea to me. My thinking was that removing the clue channel (at least explicitly) should cause the session to revert to legacy mode. (If the clue channel *fails* then one may want to assume things remain as they were for a time while trying to reestablish the channel.) ISTM that this is reasonable because the cost of maintaining the channel is low, and is really needed in case something happens that requires further signaling. And reverting to legacy mode is also a behavior that is valuable to have available. (E.g. it can be needed in the case where a the peer transfers the call to an endpoint that is clueless. This could happen when departing a TP room and continuing the call on a cell phone.) > So it seems that to continue RTP with whatever > CLUE Ids that were negotiated before would be OK behaviour. However if a > new CLUE association is started it would seem to me that any assumptions > about state should be reset. As I mentioned above, if the old association *failed* I can see working this way. Perhaps just treat the new association and channel as a continuation of the old one. The change would occur with new advertisements are exchanged over the new channel. But if the old association is gracefully shut down then perhaps revert to legacy mode. An alternative to that would be to have *explicit* signaling to revert to legacy mode, after which one could tear down the association. Another issue is who is responsible for establishing a new association if the old one fails, and when. If this isn't spelled out, then one side may explicitly close it and expect it to stay closed, while the other side decides to request a new one. >>> If there's nothing wrong with the transport the Consumer could as easily >>> send a Configure message with a code indicating "please send an updated >>> advertisement". >> >> Maybe. >> >> IMO this calls for some state machine work that can be used to >> identify significant states. Then behavior can be linked to the state. > [CNG] I'm not sure what you mean here? With the framework there's an > assumption that the consumer maintains its configuration wrt to CLUE. If > this changes or is lost then the consumer should be able to request an > updated Advertisement. I'm thinking that an endpoint "forgetting" the peer's advertisement is an error state. Then the recovery from that error state is to request, and then receive, another advertisement. This state machine would include the startup state (when both sides need to send an advertisement), a state where an advertisement has been received and a decision to send a config must be made, a normal (steady) state when nothing need be exchanged, perhaps a "legacy mode" state, and perhaps some others. It is unclear to me right now whether there should be separate state machines for providers and consumers (where most endpoints would have one of each), or a single state machine that encompasses both provider and consumer behavior. If it is done with separate state machines, then they probably need to be coupled, at least at session startup, to minimize glare conditions. Just "describing" this is inadequate. I need to actually propose something explicit here. Thanks, Paul From Christian.Groves@nteczone.com Wed Mar 27 18:06:48 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 C372221F9394 for ; Wed, 27 Mar 2013 18:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, 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 RtkzvMhJ0-F3 for ; Wed, 27 Mar 2013 18:06:48 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 089EB21F9393 for ; Wed, 27 Mar 2013 18:06:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgCAFSWU1F20UuR/2dsb2JhbAANNsIUBASBF22CZRslPRYYAwIBAgFLDQgBAbQFkyiSXwOrDQ Received: from ppp118-209-75-145.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.75.145]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Mar 2013 11:36:43 +1030 Message-ID: <5153979E.1010106@nteczone.com> Date: Thu, 28 Mar 2013 12:06:38 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Capture ID scope in a Configure 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, 28 Mar 2013 01:06:48 -0000 Hello, From the framework it seems that it is assumed CaptureIDs are unique in an Advertisement and the same CaptureID can be used in multiple scenes and CSEs. A captureID may have multiple encodings. I.e. Advertisement VC1 (capture attributes 1) VC2 (capture attributes 2) VC3 (capture attributes 3) VC4 (capture attributes 4) Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) Scene 2 (CSE1(VC1,VC4)) Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and Scene 2 CSE 1 how does it respond? a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3), Scene2(CSE1(VC1,VC4)) c) Both? d) ? In response to the Configure what does the Provider do? The consumer has indicated it wants two scenes and there's a duplicate of VC1. Should the provider send the SDP to establish only one RTP stream for VC1 or should it setup two RTP streams one for each scene? Any thoughts? Regards, Christian From apeppere@gmail.com Thu Mar 28 07:26: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 623A321F8AE3 for ; Thu, 28 Mar 2013 07:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 z9R0gcrfr+vY for ; Thu, 28 Mar 2013 07:26:16 -0700 (PDT) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3581521F8AF8 for ; Thu, 28 Mar 2013 07:26:15 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id pa12so6659822veb.12 for ; Thu, 28 Mar 2013 07:26:14 -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:cc:content-type; bh=F8EJYHPEyiFZDEwNfyhcqcn3SH5tSAOd1J+oNJL93GQ=; b=Z6SyTMTHZPk3yTIE+VKf+9IWfZ2R+jZnh67KjWi6P8TtWL+zZety8MVm3AiNb28U5d ShMA+Y2sydT+36jj8O5mF1zkFbYClDeyODhNcRCCi4nUAjwQiDyDnWCj7McwNRNCwtm9 KRJzBS/pe02ey9GV74wMf0kiIv0Z2xpq4vVtvie2Fu0lXsJ7LkHHrb5qOyQ/IWS8fvZM nt9luIB8XxF+xUQejmS/QR0d0L5ori0OrrMKFF9LFC04LTzfTWj4N8JbO4m0W8sKtOEu mEpziNQnznPsFF23mECbeXkZhX7j+uR2Dk5vcuNAcvMeXrfm4fOf09tYPdE+L2uR8tSv MmVA== MIME-Version: 1.0 X-Received: by 10.52.100.163 with SMTP id ez3mr13305117vdb.6.1364480774580; Thu, 28 Mar 2013 07:26:14 -0700 (PDT) Received: by 10.58.44.42 with HTTP; Thu, 28 Mar 2013 07:26:14 -0700 (PDT) In-Reply-To: <5153979E.1010106@nteczone.com> References: <5153979E.1010106@nteczone.com> Date: Thu, 28 Mar 2013 14:26:14 +0000 Message-ID: From: Andy Pepperell To: Christian Groves Content-Type: multipart/alternative; boundary=20cf307ca044df302904d8fcefcf Cc: "clue@ietf.org" Subject: Re: [clue] Capture ID scope in a Configure 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, 28 Mar 2013 14:26:18 -0000 --20cf307ca044df302904d8fcefcf Content-Type: text/plain; charset=ISO-8859-1 Hi Christian, I'm happy to have a go at answering your question with my opinion as to how this relates to the CLUE framework... >From the framework it seems that it is assumed CaptureIDs are unique in an Advertisement and the same CaptureID can be used in multiple scenes and CSEs. A captureID may have multiple encodings. Yes, I think that's a good summary of the uniqueness of CaptureIDs. I would, though, say that personally I consider the presence of a CaptureID in more than one scene more the exception than the rule - while it may be valid I don't think the majority of normal cases would use this. The "multiple encodings" aspect of media captures is designed to be orthogonal to media captures' presence in one or more CSEs - it may be valid to receive multiple encodings of a media capture even if it were present in just one capture scene or capture scene entry, for instance, and on the flip side, depending on the provider's advertisement, it may only be possible to receive a single encodings of a media capture which appears in multiple capture scene entries. >Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and Scene 2 CSE 1 how does it respond? To my mind, the phrasing is slightly misleading here in that it could be said that the Consumer doesn't really want "Scene 1 CSE 1" and "Scene 2 CSE 1" but in fact wants a single encoding or multiple encodings of the more fundamental "VC1", which it can put to whatever use, post decoding, that it chooses. >a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 That's what I believe to be the answer to your question. As per the above, if it has multiple "uses" for VC1, perhaps a very high quality encoding to switch out to certain other consumers and a lower quality version to transcode (if it's a middle box, for instance) it may choose to use more than one of the provider's Individual Encodings for VC1, but fundamentally this can be considered orthogonal to the choice of which media captures are needed, or the reason, based on their CSE membership, why those media captures are being requested. >In response to the Configure what does the Provider do? The consumer has indicated it wants two scenes and there's a duplicate of VC1. Should the provider send the SDP to establish only one RTP stream for VC1 or should it setup two RTP streams one for each scene? The idea behind the Encoding Group and Individual Encoding concepts was that the provider can be fairly dumb here, and need to take no view or action explicitly based on the "duplication" of VC1. SDP / RTP relationships should be made according to the encoding configuration, mostly determined by the consumer's configuration message. One RTP stream per configured encoding would seem fairly straightforward, but the multiplexing relationship of those streams with respect to "m lines", SSRCs, multiplex IDs within RTP extension headers hasn't, to my knowledge, been completely thrashed out to everyone's satisfaction as yet (though I am forced to confess to a certain amount of ignorance as to the latest state of this discussion). Regards, Andy On Thu, Mar 28, 2013 at 1:06 AM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello, > > From the framework it seems that it is assumed CaptureIDs are unique in an > Advertisement and the same CaptureID can be used in multiple scenes and > CSEs. A captureID may have multiple encodings. > > I.e. > Advertisement > VC1 (capture attributes 1) > VC2 (capture attributes 2) > VC3 (capture attributes 3) > VC4 (capture attributes 4) > Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) > Scene 2 (CSE1(VC1,VC4)) > > Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and > Scene 2 CSE 1 how does it respond? > a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 > b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3), > Scene2(CSE1(VC1,VC4)) > c) Both? > d) ? > > In response to the Configure what does the Provider do? The consumer has > indicated it wants two scenes and there's a duplicate of VC1. Should the > provider send the SDP to establish only one RTP stream for VC1 or should it > setup two RTP streams one for each scene? > > Any thoughts? > > Regards, Christian > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --20cf307ca044df302904d8fcefcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian,

I'm happy to have a go at answering yo= ur question with my opinion as to how this relates to the CLUE framework...=

>From the framework it seems that it is assume= d CaptureIDs are unique in an Advertisement and the same CaptureID can be u= sed in multiple scenes and CSEs. A captureID may have multiple encodings.

Yes, I think that's a good summary of the uniquenes= s of CaptureIDs. I would, though, say that personally I consider the presen= ce of a CaptureID in more than one scene more the exception than the rule -= while it may be valid I don't think the majority of normal cases would= use this. The "multiple encodings" aspect of media captures is d= esigned to be orthogonal to media captures' presence in one or more CSE= s - it may be valid to receive multiple encodings of a media capture even i= f it were present in just one capture scene or capture scene entry, for ins= tance, and on the flip side, depending on the provider's advertisement,= it may only be possible to receive a single encodings of a media capture w= hich appears in multiple capture scene entries.

>Now if a Consumer sends a configure in respons= e wanting Scene 1 CSE 1 and Scene 2 CSE 1 how does it respond?
To my mind, the phrasing is slightly misleading here in that i= t could be said that the Consumer doesn't really want "Scene 1 CSE= 1" and "Scene 2 CSE 1" but in fact wants a single encoding = or multiple encodings of the more fundamental "VC1", which it can= put to whatever use, post decoding, that it chooses.

>a) Does it include only the CaptureIDs? i.e. VC1,VC= 3,VC4

That's what I believe to be the answer t= o your question. As per the above, if it has multiple "uses" for = VC1, perhaps a very high quality encoding to switch out to certain other co= nsumers and a lower quality version to transcode (if it's a middle box,= for instance) it may choose to use more than one of the provider's Ind= ividual Encodings for VC1, but fundamentally this can be considered orthogo= nal to the choice of which media captures are needed, or the reason, based = on their CSE membership, why those media captures are being requested.

>In response to the Configure what does the Pr= ovider do? The consumer has indicated it wants two scenes and there's a= duplicate of VC1. Should the provider send the SDP to establish only one R= TP stream for VC1 or should it setup two RTP streams one for each scene?

The idea behind the Encoding Group and Individual Encod= ing concepts was that the provider can be fairly dumb here, and need to tak= e no view or action explicitly based on the "duplication" of VC1.= SDP / RTP relationships should be made according to the encoding configura= tion, mostly determined by the consumer's configuration message. One RT= P stream per configured encoding would seem fairly straightforward, but the= multiplexing relationship of those streams with respect to "m lines&q= uot;, SSRCs, multiplex IDs within RTP extension headers hasn't, to my k= nowledge, been completely thrashed out to everyone's satisfaction as ye= t (though I am forced to confess to a certain amount of ignorance as to the= latest state of this discussion).

Regards,

Andy

On Thu, Mar 28, 2013 at 1:06 AM, Christian Gro= ves <Christian.Groves@nteczone.com> wrote:
Hello,

>From the framework it seems that it is assumed CaptureIDs are unique in an = Advertisement and the same CaptureID can be used in multiple scenes and CSE= s. A captureID may have multiple encodings.

I.e.
Advertisement
VC1 (capture attributes 1)
VC2 (capture attributes 2)
VC3 (capture attributes 3)
VC4 (capture attributes 4)
Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2))
Scene 2 (CSE1(VC1,VC4))

Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 and S= cene 2 CSE 1 how does it respond?
a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4
b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3), Scene= 2(CSE1(VC1,VC4))
c) Both?
d) ?

In response to the Configure what does the Provider do? The consumer has in= dicated it wants two scenes and there's a duplicate of VC1. Should the = provider send the SDP to establish only one RTP stream for VC1 or should it= setup two RTP streams one for each scene?

Any thoughts?

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

--20cf307ca044df302904d8fcefcf-- From pkyzivat@alum.mit.edu Thu Mar 28 09:06:34 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 B9D4621F910C for ; Thu, 28 Mar 2013 09:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=0.104, 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 CUR+cpb6fTix for ; Thu, 28 Mar 2013 09:06:34 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECF121F910B for ; Thu, 28 Mar 2013 09:06:33 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta08.westchester.pa.mail.comcast.net with comcast id H3GS1l0011ap0As5846Zh7; Thu, 28 Mar 2013 16:06:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id H46Z1l00G3ZTu2S3i46Zfv; Thu, 28 Mar 2013 16:06:33 +0000 Message-ID: <51546A3D.1080900@alum.mit.edu> Date: Fri, 29 Mar 2013 00:05:17 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: clue@ietf.org References: <5153979E.1010106@nteczone.com> In-Reply-To: <5153979E.1010106@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=1364486793; bh=MHuhRSkfXNL1cI8IhSkXizkefSvbl0E6fC9OnunMTno=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o3BETCKTp4Ooayx5eAhvgGTDt2C/0tHhlTY2tuwl2+HT3aLbUvg0xOmYFuhLJFGtk uIthVnzVwYZ+eLPqyMW5xNVzOgmZWov7CdX9rPAW20JgNkqx2yWyQz6XtJ4Rm8tEyn LYptg0nDH9FlSfzzTNZCFbO+77OX1LIFGm86y9UV2XNrNp76lQnDxr22eYC+qX65Rs 5TJIsK9kjleA8rbczpZ3xXS18DRmobF0HAxl0vCpr0G35t1k27b7mKbR1GU9tcz4qj DYU52OU5tFiLB2X85tdTQQfyluiZ/62dZkyr9V2WCjBixQd+mjAAKzWdZNEMSq0bKx YC3m6VmCRmLqA== Subject: Re: [clue] Capture ID scope in a Configure 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, 28 Mar 2013 16:06:34 -0000 On 3/28/13 9:06 AM, Christian Groves wrote: > Hello, > > From the framework it seems that it is assumed CaptureIDs are unique in > an Advertisement and the same CaptureID can be used in multiple scenes > and CSEs. A captureID may have multiple encodings. I agree that CaptureIDs must be unique within an Advertisement. I agree that a CaptureID may be used in more than one CSE. AFAIK a CaptureID is bound to an encoding group which may contain multiple encodings. Those are *potential* encodings. The actual binding of CaptureIDs to encodings is defined by the Configure message. But yes, there it is possible to request multiple encodings of the same captureID as long as the encoding group supports that. But I don't think it makes sense for the same captureID to be used to specify a capture that is to be delivered from more than one Scene. This seems a logical impossibility - the capture has spatial coordinates that are understood within the coordinate space of the Scene in which it appears. Having the same capture in different scenes would violate that logic. If what I said is right, then there are two ways to approach encoding captureIDs: - Require that each captureID be unique within the advertisement - Require that each captureID be unique within a Scene in an Advertisement. When referenced from outside of the Scene, use a compound structure containing the SceneID and CaptureID. That is really just a pure syntactical issue, not a fundamental one. Regardless, there may be different needs for referencing CaptureIDs: - in CSEs - in Simultaneous Sets We could potentially come up with additional reasons: e.g. to define a switched capture by reference to the captures it switches among. > I.e. > Advertisement > VC1 (capture attributes 1) > VC2 (capture attributes 2) > VC3 (capture attributes 3) > VC4 (capture attributes 4) > Scene 1 (CSE1(VC1,VC3),CSE2(VC1,VC2)) > Scene 2 (CSE1(VC1,VC4)) I disagree with the validity of including VC1 in both scenes, for the reasons given above. > Now if a Consumer sends a configure in response wanting Scene 1 CSE 1 > and Scene 2 CSE 1 how does it respond? > a) Does it include only the CaptureIDs? i.e. VC1,VC3,VC4 > b) Does it include the complete reference? i.e. Scene1(CSE1(VC1,VC3), > Scene2(CSE1(VC1,VC4)) > c) Both? > d) ? You are asking how the Configure should be constructed? IMO it lists the individual CaptureIDs it wants, each paired to one of the valid encodings for that capture. AFAIK there is no need to mention scenes in Configure messages. > In response to the Configure what does the Provider do? The consumer has > indicated it wants two scenes and there's a duplicate of VC1. Should the > provider send the SDP to establish only one RTP stream for VC1 or should > it setup two RTP streams one for each scene? I think we have a disconnect in understanding, at multiple levels. We should be clarifying text to resolve such confusion. Thanks, Paul (as individual)