From roni.even@mail01.huawei.com Fri Feb 1 02:27: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 2792E21F8640 for ; Fri, 1 Feb 2013 02:27:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk4O25loSXJU for ; Fri, 1 Feb 2013 02:27:31 -0800 (PST) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id 19E1721F8629 for ; Fri, 1 Feb 2013 02:27:30 -0800 (PST) Received: from 172.24.2.15 (EHLO szxpml204-edg.exmail.huawei.com) ([172.24.2.15]) by szxrg12-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id ACZ00500; Fri, 01 Feb 2013 18:27:27 +0800 (CST) Received: from SZXPML403-HUB.exmail.huawei.com (10.82.67.164) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 1 Feb 2013 18:27:24 +0800 Received: from SZXPML504-MBX.exmail.huawei.com ([169.254.3.128]) by szxpml403-hub.exmail.huawei.com ([10.82.67.164]) with mapi id 14.01.0323.003; Fri, 1 Feb 2013 18:27:26 +0800 From: Roni Even To: "clue@ietf.org" Thread-Topic: New Version Notification for draft-even-clue-rtp-mapping-05.txt Thread-Index: AQHOAGZFhqkzxGtQfkOnEc8pSy+fOphkzFhb Date: Fri, 1 Feb 2013 10:27:25 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> In-Reply-To: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 10:27:32 -0000 ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, February 01, 2013 12:24 PM To: Roni Even Cc: jonathan@vidyo.com Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt A new version of I-D, draft-even-clue-rtp-mapping-05.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-clue-rtp-mapping Revision: 05 Title: Mapping RTP streams to CLUE media captures Creation date: 2013-02-01 WG ID: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-ma= pping-05.txt Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mappin= g Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-clue-rtp-map= ping-05 Abstract: This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. The IETF Secretariat= From roberta.presta@unina.it Sat Feb 2 09:38: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 488D821F8584 for ; Sat, 2 Feb 2013 09:38:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7ywoGbjDjc2 for ; Sat, 2 Feb 2013 09:38:47 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDDB21F8583 for ; Sat, 2 Feb 2013 09:38:47 -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 r12Hchr4005236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2013 18:38:45 +0100 Message-ID: <510D4F2B.2010304@unina.it> Date: Sat, 02 Feb 2013 18:38:51 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130202-0, 02/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [clue] clue data model updates - new version available (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: Sat, 02 Feb 2013 17:38:48 -0000 Hi all, we have just uploaded a new version of the data model draft. We have added some attributes proposed in draft-groves-capture-attr-00: - priority - embedded text - language - dynamic - language - a new element used in place of "supplementary information" () We have not added yet "view", "role" and "presentation". We have left "content" to describe the content of a capture. It seems to us that no final consensus has been reached about all of them, since mail threads have been left pending. Nonetheless, we believe the definition of keywords can help the capture selection process on the consumer side, but further discussion is needed to define them. We have moved out from the blob the description of the available media captures again. Indeed, media captures should have identifiers that are valid out of the local scope of capture scenes, since a consumer should be able to request also single captures in the CONFIGURE message. In each media capture, a reference to the capture scene containing it is provided. It identifies the space the spatial information of the media capture refers to. Comments are welcome. Cheers, Roberta & Simon From pkyzivat@alum.mit.edu Sat Feb 2 11:14: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 A422921F8864 for ; Sat, 2 Feb 2013 11:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.107, 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 PPyYwOREIw4x for ; Sat, 2 Feb 2013 11:14:37 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC4B21F85AE for ; Sat, 2 Feb 2013 11:14:36 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id vWpV1k0021uE5Es5BXEcjA; Sat, 02 Feb 2013 19:14:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id vXEb1k01A3ZTu2S3cXEc2G; Sat, 02 Feb 2013 19:14:36 +0000 Message-ID: <510D659B.3070204@alum.mit.edu> Date: Sat, 02 Feb 2013 14:14:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <510D4F2B.2010304@unina.it> In-Reply-To: <510D4F2B.2010304@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=1359832476; bh=UKa/9CkwwFcIrasdcxfjqXCaPUqb5edSXCnAQo2zc5o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Gb/MLTOHV3Zr2vuUkTRP+yJ0SkmaVfngcUSEVPvurt0pKRyoRW+cncs4LNKBAMnTq MTEtGL+76cCVI+kCAlE3p0xgrTOVAglIX6eEk/u4pZ+gvQ/JpqLGI8ORXTeltvQRjk oIS7Z04MU+1/u3krEr2/Y+9fvD5F1wBEofuUlKx7FJ8wib6GoTzZOvqyIPzY0zW78V NC5KMeEmB5ZEnbgqc2KoDxccTQFGFkZGd03Iw4O9V6IseT6+uk8u7KEKUiU4QaA7R3 eJgTg2XNH8BpEzJhlSPevgJDYorfci9Eq3HT1QPcmja0SWqAKDyFYy5eIY/+WRmock 7PARnsS/K/rMw== Subject: Re: [clue] clue data model updates - new version available (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: Sat, 02 Feb 2013 19:14:38 -0000 Hi Roberta, Thanks for the update. The first thing I noticed is that this version has several overly long lines. (idnits reports this: http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-presta-clue-data-model-schema-02.txt) The prior version also had long lines. Other comments: mediaCaptureType contains capturedMedia of type string. IIUC this is intended to correspond the the field of the m= line in SDP. Valid values of this are defined in an IANA registry. So an enumerated type would probably be better for this, or a semantic definition that the value must be one of those in that registry. There might already be an XML definition for this somewhere. We probably also want a semantic restriction that this version of CLUE only supports audio and video. I would also expect the content element to be an enumerated type, not just a string. The relatedTo element contains an IDREF. But AFAICT IDREFs aren't typed, so what kind of entity does this refer to? Is there some way to type all the IDREFs so that it is syntactically clear what each refers to? Another thing that is really a FW issue: While it makes some sense to define captureArea with four points in 3-space, Do don't think it makes sense to do that for sceneArea. We expect each captureArea to be a portion of a plane, but we don't expect all the captures in a scene to be coplanar. (They could even be arranged in a circle, so that some have axes pointing in opposite directions.) So I think the sceneArea must describe a bounding *volume*. If we restrict it to being a rectangular prism then it can be defined by two points. or we could support arbitrary hexahedrons with eight points. Thanks, Paul (as individual) On 2/2/13 12:38 PM, Roberta Presta wrote: > Hi all, > > we have just uploaded a new version of the data model draft. > > We have added some attributes proposed in draft-groves-capture-attr-00: > - priority > - embedded text > - language > - dynamic > - language > - a new element used in place of "supplementary information" () > > We have not added yet "view", "role" and "presentation". We have left > "content" to describe the content of a capture. > It seems to us that no final consensus has been reached about all of > them, since mail threads have been left pending. > Nonetheless, we believe the definition of keywords can help the capture > selection process on the consumer side, but further discussion is needed > to define them. > > We have moved out from the blob the description of the > available media captures again. > Indeed, media captures should have identifiers that are valid out of the > local scope of capture scenes, since a consumer should be able to > request also single captures in the CONFIGURE message. In each media > capture, a reference to the capture scene containing it is provided. It > identifies the space the spatial information of the media capture refers > to. > > Comments are welcome. > Cheers, > > Roberta & Simon > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Feb 4 07:53:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23EF21F882F for ; Mon, 4 Feb 2013 07:53:36 -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 NetrSZabGk7n for ; Mon, 4 Feb 2013 07:53: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 156CD21F86E7 for ; Mon, 4 Feb 2013 07:53:35 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id wBwJ1k0090ldTLk53FtbtD; Mon, 04 Feb 2013 15:53:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:c837:106c:aaf:8252]) by omta04.westchester.pa.mail.comcast.net with comcast id wFtb1k00D1na5XJ3QFtbvg; Mon, 04 Feb 2013 15:53:35 +0000 Message-ID: <510FD97E.30302@alum.mit.edu> Date: Mon, 04 Feb 2013 10:53:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: CLUE 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=1359993215; bh=fg2ud6obBqPVyLtR0f51XNaHAZqnSYIu272YnisdMMQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VU1DBkgDwDZ6mjNiTownFFFb+sDRH2PEJO52aAFgrTie3VSBTdXZILdih0xj2c+zz CLnD33wwEqC6Q84dsvuZ0b7QIZHs/TWlqllTFPkQhg8g7ZDxexISe/7ztRY+5NTojA cWcyVL1I00yrDjF5X3cQw9I6w94imC0DW6X4VSZVkBXo7HPHA6AE9v6kfgTZ1Dby4d nPZHVD2vRoY1m7kQKECDC15++65DzaqYqbBcMuuMwthOoB1jyx7Oa5DBK2/2KNU9E+ azx++9Cswzl6oF96S2SuDZNNs2Eo6edu6ESxwy87X8HBgbUHPOUZeFeWEimTBJR3in eBzgyHqt2IjjQ== Subject: [clue] no design team meeting today X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 15:53:36 -0000 Just a reminder - there will be no design team meeting today. Several people are in transit to the rtcweb/mmusic interim meeting. Thanks, Paul From roberta.presta@unina.it Mon Feb 4 08:59: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 6262121F89CE for ; Mon, 4 Feb 2013 08:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.695 X-Spam-Level: * X-Spam-Status: No, score=1.695 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 uUMo3PXtmetz for ; Mon, 4 Feb 2013 08:59:43 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFA921F89AE for ; Mon, 4 Feb 2013 08:59:43 -0800 (PST) Received: from [127.0.0.1] ([143.225.6.3]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r14GxdkO027810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 17:59:40 +0100 Message-ID: <510FE8FB.5010902@unina.it> Date: Mon, 04 Feb 2013 17:59:39 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130204-0, 04/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [clue] draft-kyzivat-clue-signaling-01 - strawman ladder diagrams added X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 16:59:44 -0000 Hi all, we just updated draft-kyzivat-clue-signaling-00. We added the ladder diagrams we showed during a recent design meeting call. Comments are welcome. Cheers, Roberta & Simon From roberta.presta@unina.it Mon Feb 4 09:18: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 D0CEA21F84E0 for ; Mon, 4 Feb 2013 09:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.488 X-Spam-Level: X-Spam-Status: No, score=0.488 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 r1jC3jvo94xC for ; Mon, 4 Feb 2013 09:18:02 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id F3CF521F8470 for ; Mon, 4 Feb 2013 09:18:01 -0800 (PST) Received: from [127.0.0.1] ([143.225.6.3]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r14HHvic005939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Feb 2013 18:17:58 +0100 Message-ID: <510FED46.7060203@unina.it> Date: Mon, 04 Feb 2013 18:17:58 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <510D4F2B.2010304@unina.it> <510D659B.3070204@alum.mit.edu> In-Reply-To: <510D659B.3070204@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130204-0, 04/02/2013), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] clue data model updates - new version available (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, 04 Feb 2013 17:18:02 -0000 Hi Paul, sorry for the long lines (and for the multiple copies of this email), I'll check them in the next version. Regarding , for the moment the simplest thing we can do is adding a semantic definition forcing the value of such element to correspond to the SDP m line value. That has been the approach adopted also in other data model RFCs (see the XML definition of the parameter in RFC4575, A SIP event package for conference state, which is the basis of RFC6501 about the XCON datamodel - http://tools.ietf.org/html/rfc4575#section-5.8.2). Alternatively, we can build an enumerative type with the options available for SDP m lines. As to the remaining open issues you listed, we can discuss them during the next design team meeting. Cheers, Roberta Il 02/02/2013 20:14, Paul Kyzivat ha scritto: > Hi Roberta, > > Thanks for the update. > > The first thing I noticed is that this version has several overly long > lines. (idnits reports this: > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-presta-clue-data-model-schema-02.txt) > The prior version also had long lines. > > Other comments: > > mediaCaptureType contains capturedMedia of type string. IIUC this is > intended to correspond the the field of the m= line in SDP. > Valid values of this are defined in an IANA registry. So an enumerated > type would probably be better for this, or a semantic definition that > the value must be one of those in that registry. There might already > be an XML definition for this somewhere. We probably also want a > semantic restriction that this version of CLUE only supports audio and > video. > > I would also expect the content element to be an enumerated type, not > just a string. > > The relatedTo element contains an IDREF. But AFAICT IDREFs aren't > typed, so what kind of entity does this refer to? Is there some way to > type all the IDREFs so that it is syntactically clear what each refers > to? > > Another thing that is really a FW issue: > > While it makes some sense to define captureArea with four points in > 3-space, Do don't think it makes sense to do that for sceneArea. > We expect each captureArea to be a portion of a plane, but we don't > expect all the captures in a scene to be coplanar. (They could even be > arranged in a circle, so that some have axes pointing in opposite > directions.) So I think the sceneArea must describe a bounding > *volume*. If we restrict it to being a rectangular prism then it can > be defined by two points. or we could support arbitrary hexahedrons > with eight points. > > Thanks, > Paul (as individual) > > On 2/2/13 12:38 PM, Roberta Presta wrote: >> Hi all, >> >> we have just uploaded a new version of the data model draft. >> >> We have added some attributes proposed in draft-groves-capture-attr-00: >> - priority >> - embedded text >> - language >> - dynamic >> - language >> - a new element used in place of "supplementary information" >> () >> >> We have not added yet "view", "role" and "presentation". We have left >> "content" to describe the content of a capture. >> It seems to us that no final consensus has been reached about all of >> them, since mail threads have been left pending. >> Nonetheless, we believe the definition of keywords can help the capture >> selection process on the consumer side, but further discussion is needed >> to define them. >> >> We have moved out from the blob the description of the >> available media captures again. >> Indeed, media captures should have identifiers that are valid out of the >> local scope of capture scenes, since a consumer should be able to >> request also single captures in the CONFIGURE message. In each media >> capture, a reference to the capture scene containing it is provided. It >> identifies the space the spatial information of the media capture refers >> to. >> >> Comments are welcome. >> Cheers, >> >> Roberta & Simon >> >> >> _______________________________________________ >> 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 Feb 6 12:50: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 E9BE121F8809 for ; Wed, 6 Feb 2013 12:50:50 -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 HVgkrbZNH9u1 for ; Wed, 6 Feb 2013 12:50:50 -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 9C22921F87B9 for ; Wed, 6 Feb 2013 12:50:49 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id x0TT1k00416LCl0538qpSd; Wed, 06 Feb 2013 20:50:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([155.212.214.60]) by omta06.westchester.pa.mail.comcast.net with comcast id x8og1k00V1JlX8B3S8oihq; Wed, 06 Feb 2013 20:48:47 +0000 Message-ID: <5112C1A8.4060801@alum.mit.edu> Date: Wed, 06 Feb 2013 15:48:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <510FE8FB.5010902@unina.it> In-Reply-To: <510FE8FB.5010902@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=1360183849; bh=rBVUh68me12E+F74gdGfzDInXFCIPOE7T1pJwht/534=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tR4L3Ob1P7is9gmeqWfIH4Tt3kz0aeYFgiawh/3YQYtdFEAnQa8uxaTaC7jB19c/k i/yzma0kXhVFiX3uzMpx4kDX5f5gSeDn6lFdU5kVVF/nOkRH3ndPkeegIBBdw7hE4v c5W3NU/PXfH7UFmBNEz/87odv39NBMLrHoZTR/W9ibAp1vQkXoM8Nw3fWtON78CHAP LRwABvzKswbwmbETknhu3cGYE40nqWB91TKHe9XDk+65vRvYBxvKrUTSBABG1EG/uM gV49UZ1jszKW1brvMG8bgu+Px/CwkaM0nQV3eyxf7lsS3RwH7+xk0gMdeGEG8imExL XS+6yCuW/eXZQ== Subject: Re: [clue] draft-kyzivat-clue-signaling-01 - strawman ladder diagrams added X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 20:50:51 -0000 Roberta, Thanks! I'm not ignoring you. I've been busy in the RTCWEB/MMUSIC interim. I'll look at it when this is over. Thanks, Paul On 2/4/13 11:59 AM, Roberta Presta wrote: > Hi all, > > we just updated draft-kyzivat-clue-signaling-00. > We added the ladder diagrams we showed during a recent design meeting call. > > Comments are welcome. > Cheers, > > Roberta & Simon > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Thu Feb 7 16:18: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 9227721F89CE for ; Thu, 7 Feb 2013 16:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 J0iHM7YjmiHf for ; Thu, 7 Feb 2013 16:18:05 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id E4D2721F8995 for ; Thu, 7 Feb 2013 16:18:04 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id j8so98264qah.13 for ; Thu, 07 Feb 2013 16:18:04 -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=gzZSyFV4fGkYXUz8taXSlbw4iLKCMWOjc3I/3oQsJrs=; b=kD+q3tq+mk/+gkUEx3etamr06qNgIspxDQsnrmGmaafwshTGIuyQUVwFuuLHTaInfc NdgWvr/0aRqa54ZYjrZOB4inPoQ6+FuokFuf800nPjnz6Bq8NCLppTtvtXb/KbEIO3uk QtAKA1EX5wp+QBRxDxKhCVsTmJr1emfnH4zqPsCs4ukuB8mr4byN8ulsE9j4MYCTu64B giwl8OBTygjEIEdrYSaRbzjfCpMIU9pmbJ27InuOyj4wx186ZLKwPwJiAMeMuhld0fKv 2yk6s4/3OD7YRe8N0FJeH2+ehashwvQjAJ0DIpVrB+9sJcbAJAcjjbXZc80vUHUjuH4X cfCA== MIME-Version: 1.0 X-Received: by 10.224.195.138 with SMTP id ec10mr1454015qab.3.1360282684340; Thu, 07 Feb 2013 16:18:04 -0800 (PST) Received: by 10.49.131.199 with HTTP; Thu, 7 Feb 2013 16:18:04 -0800 (PST) Date: Thu, 7 Feb 2013 18:18:04 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] CLUE meetings @ IETF-86 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 00:18:05 -0000 The preliminary agenda is out: https://datatracker.ietf.org/meeting/86/agenda.html We seem to have our usual Monday morning slot. Our second slot is Thursday afternoon. That should allow some discussions in between and perhaps we can make some progress. Note that it's become increasingly clear to those of us that just sat through 3 days of WebRTC/RTCWEB/MMUSIC that there is still a lot of work to be done to support multiple media streams- whatever "media streams" means since it's clear that the definition of such is not clear. I think it's important for CLUE participants to be following the work in MMUSIC as it is relevant to CLUE unless we want multiple ways of doing the exact same thing. Regards, Mary. From john@jlc.net Fri Feb 8 07:18: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 2592F21F8A4B for ; Fri, 8 Feb 2013 07:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.048 X-Spam-Level: X-Spam-Status: No, score=-106.048 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 b9UftOYzFilH for ; Fri, 8 Feb 2013 07:18:06 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 67AAD21F8A6E for ; Fri, 8 Feb 2013 07:18:06 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 92C5A33CEA; Fri, 8 Feb 2013 10:18:06 -0500 (EST) Date: Fri, 8 Feb 2013 10:18:06 -0500 From: John Leslie To: Mary Barnes Message-ID: <20130208151806.GE65123@verdi> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: CLUE Subject: Re: [clue] CLUE meetings @ IETF-86 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 15:18:07 -0000 Mary Barnes wrote: > > Note that it's become increasingly clear to those of us that just sat > through 3 days of WebRTC/RTCWEB/MMUSIC that there is still a lot of > work to be done to support multiple media streams- I only "sat through" two of those days; but I'll say what Mary tried to avoid saying: not merely is there a lot of work to be done, there's little consensus what that work is and less consensus on what path to pursue. There were a bunch of very good folks there; and when I left Wednesday a half-dozen of them were plotting a way forward. They need _active_ support! > whatever "media streams" means since it's clear that the definition > of such is not clear. There was actually something approaching consensus that they wouldn't be able to reach consensus on what it means. ;^) (I recommend listening to the audio so you can learn how to say "avocado" and evoke peals of laughter.) > I think it's important for CLUE participants to be following the work > in MMUSIC "Following" isn't enough. We need some CLUE people _participating_ in MMUSIC to make it clear that multiple streams of media is a MUST support issue (and what _we_ mean by that). Several proposals are out there with differing levels of pain for CLUE -- but we cannot do our work reasonably while we have to design for all of them (without knowing which will actually be available). > as it is relevant to CLUE unless we want multiple ways of doing the > exact same thing. This isn't stated quite right, IMHO. If we _have_ multiple ways of doing the same thing, we can _design_for_ those multiple ways. What we're looking at now is near-total uncertainty about which of the proposed multiple ways (if any) may get blessed by MMUSIC. (Nobody there actually _liked_ having multiple ways; but there was so much tenacity about differing proposals that it's unclear whether they can reach consensus to discard any of them. IMHO we're better off having to work around multiple ways than waiting for Godot, only to find that what we've been assuming ends up being forbidden.) YMMV, obviously... but unless we participate in MMUSIC I worry that progress there will continue to be glacial. -- John Leslie From ron.even.tlv@gmail.com Fri Feb 8 10:02:37 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 A63F021F8A6E for ; Fri, 8 Feb 2013 10:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.776 X-Spam-Level: X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=0.823, 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 b8HFfw-tprNf for ; Fri, 8 Feb 2013 10:02:37 -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 C9BF721F8A52 for ; Fri, 8 Feb 2013 10:02:36 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so2207176eek.34 for ; Fri, 08 Feb 2013 10:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=GZBHLECeUjBmvf0/F/VvJE15rk+AVUmFCkq1zn6V5Eo=; b=cZipMI49GnGhukb2qJx+Viql7+r9eq+XyrAwCHMHVWe8bch5YcwTk68/aMoyf6C9yZ nwB9PlmmXMudWyZPNkDd0wGqC1PWPgMgxOLOXIFBHKS2mnzFzmVErUKTw15ao/nZDdht zZI9QXKBDSe7BQuP7+L68wH3Vf3HSbQPI3zdNFfLABdLChYbbBP44UdilYnzFduqkXrH VN7I3bNt914X0Px0cozKJb/Te4zvadHxYEc7KiL8s09InmJNJMFt+KzF/p0pmRcUv+Ab HfrYTD/jXQXBUwTbrR9kmIg1KEuaNdYxpm02XLAykmcbo7H1wPp1qjIcm58aPp+747DO AK4g== X-Received: by 10.14.179.5 with SMTP id g5mr18258128eem.41.1360346555721; Fri, 08 Feb 2013 10:02:35 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id h5sm48542692eem.1.2013.02.08.10.02.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 Feb 2013 10:02:34 -0800 (PST) From: "Roni Even" To: "'John Leslie'" , "'Mary Barnes'" References: <20130208151806.GE65123@verdi> In-Reply-To: <20130208151806.GE65123@verdi> Date: Fri, 8 Feb 2013 19:59:43 +0200 Message-ID: <060c01ce0626$14ea8200$3ebf8600$@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: AQI/nvLg+dy6f2RPO95WmazWvDo3MwHu9O4Jl32Vz5A= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] CLUE meetings @ IETF-86 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 18:02:37 -0000 Hi John, I fully agree with your concerns and I even posted before the meeting that it should have also been a CLUE interim meeting. I believe that most of the contributions to MMUSIC are from people who also follow CLUE. I think that the relevant work in CLUE is with the RTP mapping draft and we will try to see how the direction in MMUSIC affect it. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of John Leslie Sent: 08 February, 2013 5:18 PM To: Mary Barnes Cc: CLUE Subject: Re: [clue] CLUE meetings @ IETF-86 Mary Barnes wrote: > > Note that it's become increasingly clear to those of us that just sat > through 3 days of WebRTC/RTCWEB/MMUSIC that there is still a lot of > work to be done to support multiple media streams- I only "sat through" two of those days; but I'll say what Mary tried to avoid saying: not merely is there a lot of work to be done, there's little consensus what that work is and less consensus on what path to pursue. There were a bunch of very good folks there; and when I left Wednesday a half-dozen of them were plotting a way forward. They need _active_ support! > whatever "media streams" means since it's clear that the definition of > such is not clear. There was actually something approaching consensus that they wouldn't be able to reach consensus on what it means. ;^) (I recommend listening to the audio so you can learn how to say "avocado" and evoke peals of laughter.) > I think it's important for CLUE participants to be following the work > in MMUSIC "Following" isn't enough. We need some CLUE people _participating_ in MMUSIC to make it clear that multiple streams of media is a MUST support issue (and what _we_ mean by that). Several proposals are out there with differing levels of pain for CLUE -- but we cannot do our work reasonably while we have to design for all of them (without knowing which will actually be available). > as it is relevant to CLUE unless we want multiple ways of doing the > exact same thing. This isn't stated quite right, IMHO. If we _have_ multiple ways of doing the same thing, we can _design_for_ those multiple ways. What we're looking at now is near-total uncertainty about which of the proposed multiple ways (if any) may get blessed by MMUSIC. (Nobody there actually _liked_ having multiple ways; but there was so much tenacity about differing proposals that it's unclear whether they can reach consensus to discard any of them. IMHO we're better off having to work around multiple ways than waiting for Godot, only to find that what we've been assuming ends up being forbidden.) YMMV, obviously... but unless we participate in MMUSIC I worry that progress there will continue to be glacial. -- John Leslie _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Feb 8 10:19: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 D3F0821F8B0E for ; Fri, 8 Feb 2013 10:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.092, 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 tR4T+cScx7Gn for ; Fri, 8 Feb 2013 10:19:58 -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 0EEBA21F8B11 for ; Fri, 8 Feb 2013 10:19:57 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id xrGM1k0040xGWP85EuKvch; Fri, 08 Feb 2013 18:19:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id xuKv1k00A3ZTu2S3YuKvTQ; Fri, 08 Feb 2013 18:19:55 +0000 Message-ID: <511541CA.50701@alum.mit.edu> Date: Fri, 08 Feb 2013 13:19:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <20130208151806.GE65123@verdi> <060c01ce0626$14ea8200$3ebf8600$@gmail.com> In-Reply-To: <060c01ce0626$14ea8200$3ebf8600$@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=1360347595; bh=3RhxZZAK3DblfItGdqaPUPBKDyhj0ovtVurJhtE/3LY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZqNkRcD2ixFVVUDgf9QAaPb+POYiOwiPK718ooW1Kv1SVdHaKpLLJ1dERVF8Va1Sy RV5XYi6+jfVKQ8Aw2IJjhpAXArQXJz7IJmlSlh487jDdiVd19RUGFvB3OIyOWnaq0t kxYHxGXN3Q7n2bt36xu+zoMPfYEjSQLh5yV5OMBigiLS4NxFu/MAfZz0lwR8ZvJA8M wxsVc+Mhb9DDmELZ5wWLm29SnEpZuyc1eR19i/qYiFMkxVNNkWx8ct6KdbBDzowRGQ jL4A3V/2dEv6V50xX9uwvB1BU0SYgoYLeteG7HFbBYm6nZCaq5Se62Rs3g25rxAlRQ WUAC2G4w57iIw== Subject: Re: [clue] CLUE meetings @ IETF-86 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 18:19:59 -0000 On 2/8/13 12:59 PM, Roni Even wrote: > Hi John, > I fully agree with your concerns and I even posted before the meeting that > it should have also been a CLUE interim meeting. It would not have worked to have a concurrent CLUE meeting. This was an intense three days and people were frazzled. > I believe that most of the contributions to MMUSIC are from people who also > follow CLUE. Not so much recently. There are clearly a bunch of RTCWEB people who have had to become MMUSIC contributors who only follow clue slightly if at all. Several don't really understand SIP either. But there *are* several of us who are active in CLUE who also follow MMUSIC closely. Until now I have refrained from doing much on behalf of CLUE because it wasn't clear to me exactly what would be the right thing to do. > I think that the relevant work in CLUE is with the RTP mapping draft and we > will try to see how the direction in MMUSIC affect it. We also need to either take a stand on the bundling issue, or else convince ourselves that anything being proposed for that will meet our needs. Until recently I was of the opinion that either "bundle" or "mmt" would work for CLUE. But that was partly based on them being "fuzzy". This needs to be continually watched. I've also been commenting actively on the SCTP-SDP draft the ensure that what comes out of that will work for CLUE to negotiate its CLUE channel, for both native SIP clue endpoints and ones that are browser-rtcweb-based. Thanks, Paul > Roni > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of John > Leslie > Sent: 08 February, 2013 5:18 PM > To: Mary Barnes > Cc: CLUE > Subject: Re: [clue] CLUE meetings @ IETF-86 > > Mary Barnes wrote: >> >> Note that it's become increasingly clear to those of us that just sat >> through 3 days of WebRTC/RTCWEB/MMUSIC that there is still a lot of >> work to be done to support multiple media streams- > > I only "sat through" two of those days; but I'll say what Mary tried to > avoid saying: not merely is there a lot of work to be done, there's little > consensus what that work is and less consensus on what path to pursue. > > There were a bunch of very good folks there; and when I left Wednesday a > half-dozen of them were plotting a way forward. They need _active_ support! > >> whatever "media streams" means since it's clear that the definition of >> such is not clear. > > There was actually something approaching consensus that they wouldn't be > able to reach consensus on what it means. ;^) > > (I recommend listening to the audio so you can learn how to say "avocado" > and evoke peals of laughter.) > >> I think it's important for CLUE participants to be following the work >> in MMUSIC > > "Following" isn't enough. We need some CLUE people _participating_ in > MMUSIC to make it clear that multiple streams of media is a MUST support > issue (and what _we_ mean by that). Several proposals are out there with > differing levels of pain for CLUE -- but we cannot do our work reasonably > while we have to design for all of them (without knowing which will actually > be available). > >> as it is relevant to CLUE unless we want multiple ways of doing the >> exact same thing. > > This isn't stated quite right, IMHO. If we _have_ multiple ways of doing > the same thing, we can _design_for_ those multiple ways. What we're looking > at now is near-total uncertainty about which of the proposed multiple ways > (if any) may get blessed by MMUSIC. > > (Nobody there actually _liked_ having multiple ways; but there was so > much tenacity about differing proposals that it's unclear whether they can > reach consensus to discard any of them. IMHO we're better off having to work > around multiple ways than waiting for Godot, only to find that what we've > been assuming ends up being forbidden.) > > YMMV, obviously... but unless we participate in MMUSIC I worry that > progress there will continue to be glacial. > > -- > John Leslie > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Sat Feb 9 12:16: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 23A1521F85EE for ; Sat, 9 Feb 2013 12:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Ycu6nTnNJOXF for ; Sat, 9 Feb 2013 12:16:29 -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 C29C221F85DB for ; Sat, 9 Feb 2013 12:16:29 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id g10so742030qah.18 for ; Sat, 09 Feb 2013 12:16:28 -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=gE50hiH55xLquQDuWSzbH/d7JYog1aUbYew9KkMFEGU=; b=pelzIWcS2nWro6oUbZPeI2HZbsNnyamz3kdTVBgUiwkp74cI4Q4aZ+1CB07VmMDAE1 0YdkZvxI7vC5G+Z/1ViXZkrk4zfhS4df0UtQeX10mNSmBQeXZF9uuhivREI0XNaUfNcN HjpN5oVdwgDJJtdoXMZVvDgBvvVwoyUA7x5FBX2XL/APLUSaBmTLP56rPQI7LyuedslH vkmRJitOqau/BHffN4Xk+ppoTKZSL77Y0GQoF4MMwf7X1s7PgiNwI2vKLRbMvW0RJo+0 CwY9XWE6Leu0+pbZNNaWmmItCnvtW/CbS7S3SsmriQmnuF456FtieGz4X+dpB+xQiKIw YEhA== MIME-Version: 1.0 X-Received: by 10.49.72.136 with SMTP id d8mr3950497qev.62.1360440988591; Sat, 09 Feb 2013 12:16:28 -0800 (PST) Received: by 10.49.131.199 with HTTP; Sat, 9 Feb 2013 12:16:28 -0800 (PST) In-Reply-To: <20130208151806.GE65123@verdi> References: <20130208151806.GE65123@verdi> Date: Sat, 9 Feb 2013 14:16:28 -0600 Message-ID: From: Mary Barnes To: John Leslie Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] CLUE meetings @ IETF-86 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2013 20:16:31 -0000 On Fri, Feb 8, 2013 at 9:18 AM, John Leslie wrote: > Mary Barnes wrote: >> >> Note that it's become increasingly clear to those of us that just sat >> through 3 days of WebRTC/RTCWEB/MMUSIC that there is still a lot of >> work to be done to support multiple media streams- > > I only "sat through" two of those days; but I'll say what Mary tried > to avoid saying: not merely is there a lot of work to be done, there's > little consensus what that work is and less consensus on what path to > pursue. > > There were a bunch of very good folks there; and when I left Wednesday > a half-dozen of them were plotting a way forward. They need _active_ > support! > >> whatever "media streams" means since it's clear that the definition >> of such is not clear. > > There was actually something approaching consensus that they wouldn't > be able to reach consensus on what it means. ;^) > > (I recommend listening to the audio so you can learn how to say > "avocado" and evoke peals of laughter.) > >> I think it's important for CLUE participants to be following the work >> in MMUSIC > > "Following" isn't enough. We need some CLUE people _participating_ > in MMUSIC to make it clear that multiple streams of media is a MUST > support issue (and what _we_ mean by that). Several proposals are out > there with differing levels of pain for CLUE -- but we cannot do our > work reasonably while we have to design for all of them (without > knowing which will actually be available). [MB] My point was with regards to folks that haven't been following *any* of the work in RTCWEB that is being fed into MMUSIC. I think we had everyone that has been following & more importantly contributing except Roni at the meeting. Other folks that are working on a signaling solution really do need to understand how CLUE will be using SDP. [/MB] > >> as it is relevant to CLUE unless we want multiple ways of doing the >> exact same thing. > > This isn't stated quite right, IMHO. If we _have_ multiple ways of > doing the same thing, we can _design_for_ those multiple ways. What > we're looking at now is near-total uncertainty about which of the > proposed multiple ways (if any) may get blessed by MMUSIC. > > (Nobody there actually _liked_ having multiple ways; but there was > so much tenacity about differing proposals that it's unclear whether > they can reach consensus to discard any of them. IMHO we're better > off having to work around multiple ways than waiting for Godot, only > to find that what we've been assuming ends up being forbidden.) [MB] I had side discussions about us ending up with multiple ways. If we end up with multiple ways (which is certainly likely based upon where RTCWEB is right now), then we still have issues with interop. At this point we are most likely going to have to do quite a bit (somewhere in the middle) to get RTCWEB to work with a CLUE client, for example, and even to interop with a "legacy" SIP client. [/MB] > > YMMV, obviously... but unless we participate in MMUSIC I worry > that progress there will continue to be glacial. [MB] Again, I think that we have participants, the problem is that we haven't agreed the details for the CLUE signaling thus we don't really know what solution we would need in MMUSIC. I don't think we'll end up with an optimal solution and I think part of it is due to the fact that SDP is just so overloaded right now and is being pushed to the limits of it's original design intent. That's why my preference would be for CLUE to do the minimum in SDP and leave as much as possible for the CLUE protocol to allow flexibility and extensibility in the solution. Otherwise, it will be a nightmare to extend CLUE and we really don't achieve some of our primary objectives.[/MB] > > -- > John Leslie From mary.ietf.barnes@gmail.com Sat Feb 9 12:22: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 10BBC21F85DC for ; Sat, 9 Feb 2013 12:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 B0fPy+T06Svj for ; Sat, 9 Feb 2013 12:22:24 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3B521F85DB for ; Sat, 9 Feb 2013 12:22:24 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id j3so1828129qcs.34 for ; Sat, 09 Feb 2013 12:22:23 -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:content-type; bh=MwUznylvIqrqhsvJJrBF8M0SDH4m8GCcKY4FESJVgKM=; b=ouZmCGTb7PIRhybDLioGQjWVoU1aqavw14u59hKEBHEGBHvWxVgCeK3zyO+jJYyx5R 8d5n0aQK4R05w2dnTYB9WSodI1aD24eiHzM3FU2B+sgEcmTQRFF1y8X/kJ1chR2Hkpwk mZ+DQv8ez92jcshzMvZkYl25FxA+cQabXv2IST/6Ci0evhZ301Xqd7XitHZYXbTsStkB /CIFmyGLpYtqvoGwHisJD4TUAtmBUtEl/WGhuF836xQxeeimnjZ5IiJOV3wIzZOOpQlU eWg1FtD8+pX43SDu2ee5tgxmH6kgEie7L8g3xn2XTqIlf+MpIt5j6bhx4cQP1MoGVwvV ngww== MIME-Version: 1.0 X-Received: by 10.224.195.138 with SMTP id ec10mr3604936qab.3.1360441343774; Sat, 09 Feb 2013 12:22:23 -0800 (PST) Received: by 10.49.131.199 with HTTP; Sat, 9 Feb 2013 12:22:23 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF013DF6F4@MCHP04MSX.global-ad.net> Date: Sat, 9 Feb 2013 14:22:23 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: [MMUSIC] Requirements for Bundle, Fumble etc. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Feb 2013 20:22:25 -0000 I think it's extremely important for CLUE to look at these requirements and determine whether they are sufficient for CLUE. Regards, Mary. ---------- Forwarded message ---------- From: Hutton, Andrew Date: Fri, Feb 8, 2013 at 9:01 PM Subject: [MMUSIC] Requirements for Bundle, Fumble etc. To: "mmusic@ietf.org (E-mail)" Hi, I suggest that the requirements discussed at the interim (http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-10.pdf) regarding bundling on to a single 5-tuple need the following additional requirements. 1. Must work for a dual stack client when ICE candidates are used for address family negotiation. I think this is interesting because in this scenario there will of course be different candidates for each address family and we will probably need some rules to make sure this works. 2. Must work when a TURN server is used. This is interesting because although a single TURN allocation will be needed for the bundled candidates it will I assume be necessary to do additional TURN allocations just in case the peer does not support bundle. Regards Andy _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From Christian.Groves@nteczone.com Sun Feb 10 21:15: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 63B6021F890F for ; Sun, 10 Feb 2013 21:15:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgyzGwMRUcoZ for ; Sun, 10 Feb 2013 21:15:36 -0800 (PST) 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 54C7C21F8900 for ; Sun, 10 Feb 2013 21:15:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABN9GFF20b9x/2dsb2JhbAANNsEsgxIBAQEDORslATwMChgDAgECAUsNAQcBAYgIrGGSTY02C4EWgzYDkmqXJ4Fb Received: from ppp118-209-191-113.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.191.113]) by ipmail07.adl2.internode.on.net with ESMTP; 11 Feb 2013 15:45:31 +1030 Message-ID: <51187E70.6020104@nteczone.com> Date: Mon, 11 Feb 2013 16:15:28 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Framework updates X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 05:15:38 -0000 Given that the deadline for submissions for the Orlando coming I thought I spend some time going back through some threads on the framework. During the discussions of the concepts of scene, capture scene, capture scene entry etc. I think we came up with several places where the framework should be updated. These weren't picked up in the v8 update of the framework. I've outlined them below: 1. MCU terminating CLUE ----------------------- (thread: MCU terminating CLUE, or passing through? was: Capture scene clarifications) There was some discussion whether it was assumed that MCUs passed messages through or MCUs terminated the CLUE signalling. It appeared that the people thought (Stephen W words): "that it is the responsibility of an MCU to consolidate room information it has received from receiving rooms and provide, based on its unified view, sensible choices for things like the selection of Capture scenes." I believe something like the above text should be added to the framework. 2. Capture Scene Clarifications ------------------------------- I made some proposals to clarify the capture scene concept that appeared to be accepted by the Mark. See "Re: [clue] Capture scene clarifications 2/12/2012". > 1) Introduce a new definition for "Scene". The capture scene definition and > several places mention "scene" but there's no explanation. I propose the > following definition to be added to section 3 of the draft: > Scene: Represents an area where the capture devices are spatially related. > Non-spatially related devices exist in different scenes. > 2) Update the definition of "Capture scene entry" to make it clearer that it > represents an entire scene. Proposed text is: > *Capture Scene Entry: a list of media captures of the same media type > that together form one representation of an entire capture scene. > 3) Update section 6.2 on Capture scenes to reflect the above intents. > Changes proposals are: > - Section 6.2 2nd paragraph: > "A capture scene is a structure representing the <> scene that is > captured by a collection of<>capture devices. A capture > scene..." > - Section 6.2 3rd paragraph: > "A provider may advertise multiple capture scenes or just a single > capture scene.<> > A media provider might typically use one capture > scene for main participant media and another capture scene for a > computer generated presentation...." > 4) The framework uses the terms "media provider" and "provider". We > probably should be consistent in the use of the term throughout the > framework. 3. Prioritisation ----------------- There was some discussion regarding whether any prioritization could be assumed from the order of captures (or any other element) in the structures in the framework. I think it was agreed that the framework didn't consider this. I think it should be clarified in the framework that no prioritisation is assumed. 4. Captures in more than one capture scene entry ------------------------------------------------ The framework doesn't explicitly state that the same capture can be in more than one capture scene entry. The examples seem to suggest only one capture scene entry at a time. I assume though that a capture may reside in multiple capture scene entries. Explicit text should be added for clarity. 5. Are simultaneous set mandatory? ---------------------------------- Simultaneous sets are defined in the framework but there is no explicit text indicating whether they are mandatory or optional for the Advertiser to send. Consumer side procedures would need to align with being mandatory or optional. I proposed some "hybrid" behaviour which seemed to have some support, i.e. "For a particular media type the consumer should choose one capture scene entry. If the advertiser has provided a simultaneous transmission set, the consumer may choose individual captures taking in account any simultaneity requirements". This support may need to be confirmed. 6. Sending a configure ---------------------- (See thread [clue] Sending a configure 13/12/2012) There is some confusion regarding autonomous sending of configure messages. In response to the comments I propose to add the following: "Once the consumer has received an advertisement it may change its configuration of the provider's encodings any number of times during the call in response to signalling or other event by sending a new configure message." 7. Capture Attributes --------------------- I'll address the addition of capture attributes in another email. Framework editors, how to proceed to address the above items? Regards, Christian From mary.ietf.barnes@gmail.com Mon Feb 11 06:53: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 55C7A21F8917 for ; Mon, 11 Feb 2013 06:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 efSn4AeXGVIs for ; Mon, 11 Feb 2013 06:53:48 -0800 (PST) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id C492221F892A for ; Mon, 11 Feb 2013 06:53:48 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id 1so2610521qeb.13 for ; Mon, 11 Feb 2013 06:53:48 -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=AkleLsQRY/QTze3+CzpWEmnJN+OtVPPdqaGykruenfY=; b=IJ10jejlqrOOFsAyM7FZvXV4H6mvv6QECuA5VUkYH8eFPo9ZxLq2j0DX4qM4M8hpQR Mi4M63Qv2hpY5rEBgB+zcXQElTkBbEmFh2FcKwGma7m53DbqSU1bZRy/F2RG+uesEu0U t4KiwkjOM6/FvbTkbYspSQsqnZBUbBuEt4FGN19HXBoGOl+mIo9hCtIw0gUdp/KzNym0 1GLyRl+AFoEST6nrg/5VdS9VbeAAPAO60g455o/844SLorMvBT3Gd3oLktpOWGbfoquS NZlThNc+Jesho3K/zIKlEAK62V5lsfA46zmwI9+OpAKFKwtTWeQzADyv3Rf4V6d+os0U 2FFg== MIME-Version: 1.0 X-Received: by 10.49.29.135 with SMTP id k7mr6404394qeh.39.1360594428332; Mon, 11 Feb 2013 06:53:48 -0800 (PST) Received: by 10.49.131.199 with HTTP; Mon, 11 Feb 2013 06:53:48 -0800 (PST) Date: Mon, 11 Feb 2013 08:53:48 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Design Team meeting today (Feb. 11th) @ 10am Central X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 14:53:49 -0000 HI all, The meeting is on for today. Given that there is just one week before the -00 deadline and two before the final draft deadline for IETF-86, we have a number of things we should go over: 1) Populating the signaling document: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/ 2) Feedback on RTCWEB/MMUSIC interim meeting (as time allows) Regards, Mary From mary.ietf.barnes@gmail.com Mon Feb 11 08:55: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 3C86D21F8A80 for ; Mon, 11 Feb 2013 08:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ozjjI0rCIMuS for ; Mon, 11 Feb 2013 08:55:01 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3E29B21F8A79 for ; Mon, 11 Feb 2013 08:55:01 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id hg5so1244147qab.6 for ; Mon, 11 Feb 2013 08:55:00 -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=ZS1EBn8u6CXYBxdVm30JdRFtAEikiKFKFHnpBTn/aW0=; b=Ir1VJKHThCT5xdMjL6+ZJKLpfehdrOv0Cb9s5JSmo9P0T4kcG3WKhY8UhYEEniaLT4 GRd9N5y10/reh7H5nTsYz9n6mjZSfBQoFhTmMBMTk8XOD00zKhc4+FAAN//4OAPXjrhV WgXSoaBYbpXUoAD5uVD+16zvBw4aA1w1RwP0DvziOs2k/dNMg8MyF9eTTBu7HKt3HYh9 HYW2xGHqkVqpkp7lgSZJv+vga+jtWi0irLNYzIPSFdibBrmNlCEI7aX0iFhssnWEUe8g vVrrChHSsyGZYBs9YsXcNhzhLL/q91n7TKa5VfiAYWppn8M4asiheMrYlgKmt/l6WE9A L60w== MIME-Version: 1.0 X-Received: by 10.229.171.3 with SMTP id f3mr1351694qcz.41.1360601700468; Mon, 11 Feb 2013 08:55:00 -0800 (PST) Received: by 10.49.131.199 with HTTP; Mon, 11 Feb 2013 08:55:00 -0800 (PST) In-Reply-To: <51187E70.6020104@nteczone.com> References: <51187E70.6020104@nteczone.com> Date: Mon, 11 Feb 2013 10:55:00 -0600 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: text/plain; charset=ISO-8859-1 Cc: "clue@ietf.org" Subject: Re: [clue] Framework updates X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 16:55:02 -0000 On Sun, Feb 10, 2013 at 11:15 PM, Christian Groves wrote: > Given that the deadline for submissions for the Orlando coming I thought I > spend some time going back through some threads on the framework. > > During the discussions of the concepts of scene, capture scene, capture > scene entry etc. I think we came up with several places where the framework > should be updated. These weren't picked up in the v8 update of the > framework. I've outlined them below: > > 1. MCU terminating CLUE > ----------------------- > (thread: MCU terminating CLUE, or passing through? was: Capture scene > clarifications) > There was some discussion whether it was assumed that MCUs passed messages > through or MCUs terminated the CLUE signalling. It appeared that the people > thought (Stephen W words): > "that it is the responsibility of an MCU to consolidate room information it > has received from receiving rooms and provide, based on its unified view, > sensible choices for things like the selection of Capture scenes." > > I believe something like the above text should be added to the framework. > > 2. Capture Scene Clarifications > ------------------------------- > I made some proposals to clarify the capture scene concept that appeared to > be accepted by the Mark. See "Re: [clue] Capture scene clarifications > 2/12/2012". > >> 1) Introduce a new definition for "Scene". The capture scene definition >> and >> several places mention "scene" but there's no explanation. I propose the >> following definition to be added to section 3 of the draft: >> Scene: Represents an area where the capture devices are spatially related. >> Non-spatially related devices exist in different scenes. > >> 2) Update the definition of "Capture scene entry" to make it clearer that >> it >> represents an entire scene. Proposed text is: >> *Capture Scene Entry: a list of media captures of the same media type >> that together form one representation of an entire capture scene. > >> 3) Update section 6.2 on Capture scenes to reflect the above intents. >> Changes proposals are: >> - Section 6.2 2nd paragraph: >> "A capture scene is a structure representing the <> scene that is >> captured by a collection of<>capture devices. A >> capture >> scene..." > >> - Section 6.2 3rd paragraph: >> "A provider may advertise multiple capture scenes or just a single >> capture scene.<> provider.>> >> A media provider might typically use one capture >> scene for main participant media and another capture scene for a >> computer generated presentation...." > >> 4) The framework uses the terms "media provider" and "provider". We >> probably should be consistent in the use of the term throughout the >> framework. > > 3. Prioritisation > ----------------- > There was some discussion regarding whether any prioritization could be > assumed from the order of captures (or any other element) in the structures > in the framework. I think it was agreed that the framework didn't consider > this. I think it should be clarified in the framework that no prioritisation > is assumed. > > 4. Captures in more than one capture scene entry > ------------------------------------------------ > The framework doesn't explicitly state that the same capture can be in more > than one capture scene entry. The examples seem to suggest only one capture > scene entry at a time. I assume though that a capture may reside in multiple > capture scene entries. Explicit text should be added for clarity. > > 5. Are simultaneous set mandatory? > ---------------------------------- > Simultaneous sets are defined in the framework but there is no explicit text > indicating whether they are mandatory or optional for the Advertiser to > send. Consumer side procedures would need to align with being mandatory or > optional. > I proposed some "hybrid" behaviour which seemed to have some support, i.e. > > "For a particular media type the consumer should choose one capture scene > entry. If the advertiser has provided a simultaneous transmission set, the > consumer may choose individual captures taking in account any simultaneity > requirements". > > This support may need to be confirmed. > > 6. Sending a configure > ---------------------- > (See thread [clue] Sending a configure 13/12/2012) > There is some confusion regarding autonomous sending of configure messages. > In response to the comments I propose to add the following: > "Once the consumer has received an advertisement it may change its > configuration of the provider's encodings any number of times during the > call in response to signalling or other event by sending a new configure > message." > > 7. Capture Attributes > --------------------- > I'll address the addition of capture attributes in another email. > > Framework editors, how to proceed to address the above items? [MB] We actually need the WG to agree with the proposed changes before the FW editors should make changes (that's the IETF model for WG documents). Therefore, we really need CLUE WG participants to review this and respond so the FW editors can make any necessary changes before the draft deadline. [/MB] > > Regards, Christian > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Feb 11 13:20: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 DD65F21F8828 for ; Mon, 11 Feb 2013 13:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=0.086, 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 h-CE7XdO8UgM for ; Mon, 11 Feb 2013 13:20:25 -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 C5FDD21F8659 for ; Mon, 11 Feb 2013 13:20:24 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id z1hA1k00516LCl0539LQuy; Mon, 11 Feb 2013 21:20:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id z9LQ1k0013ZTu2S3S9LQlW; Mon, 11 Feb 2013 21:20:24 +0000 Message-ID: <51196097.8020109@alum.mit.edu> Date: Mon, 11 Feb 2013 16:20:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <51187E70.6020104@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=1360617624; bh=VDQU0IwWGkcmqs5cEWNJEUo7Q6fUf152aK5Ifvyf/Hg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=PZKwboYc3NznOLUpraqjUWqBu/PV9Im/fz0hfOOy0txXhmbQ1BxpQJEQruneOxrh5 HuoAtTllTCPGRVIx28AVhCv0mryDvWhouvTf4k9FQQvjlM5CNS/ZJj7EdbSXlGoJRX RfMn2gUUKwoEhm6NlbfaAei1PljWJl/ImkazmEoxMr9UAA0FQ/RMXkvEphUa1F82mp XEGgXauLslrXthk4G/TavmJxWs+fplsMqMMY3dVInXV4KDven9LR/qx/pek3RTsSbJ UJgD73GtOkjZOMbAJ2B0CsFBEperJkC7roW08VndnPakeEn54kv2s+kI14v/d+KDni WYuuYAJ17eqDg== Subject: Re: [clue] Framework updates X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 21:20:26 -0000 (Replying as an individual) On 2/11/13 11:55 AM, Mary Barnes wrote: > On Sun, Feb 10, 2013 at 11:15 PM, Christian Groves > wrote: >> Given that the deadline for submissions for the Orlando coming I thought I >> spend some time going back through some threads on the framework. >> >> During the discussions of the concepts of scene, capture scene, capture >> scene entry etc. I think we came up with several places where the framework >> should be updated. These weren't picked up in the v8 update of the >> framework. I've outlined them below: >> >> 1. MCU terminating CLUE >> ----------------------- >> (thread: MCU terminating CLUE, or passing through? was: Capture scene >> clarifications) >> There was some discussion whether it was assumed that MCUs passed messages >> through or MCUs terminated the CLUE signalling. It appeared that the people >> thought (Stephen W words): >> "that it is the responsibility of an MCU to consolidate room information it >> has received from receiving rooms and provide, based on its unified view, >> sensible choices for things like the selection of Capture scenes." >> >> I believe something like the above text should be added to the framework. +1 >> 2. Capture Scene Clarifications >> ------------------------------- >> I made some proposals to clarify the capture scene concept that appeared to >> be accepted by the Mark. See "Re: [clue] Capture scene clarifications >> 2/12/2012". >> >>> 1) Introduce a new definition for "Scene". The capture scene definition >>> and >>> several places mention "scene" but there's no explanation. I propose the >>> following definition to be added to section 3 of the draft: >>> Scene: Represents an area where the capture devices are spatially related. >>> Non-spatially related devices exist in different scenes. +1 >>> 2) Update the definition of "Capture scene entry" to make it clearer that >>> it >>> represents an entire scene. Proposed text is: >>> *Capture Scene Entry: a list of media captures of the same media type >>> that together form one representation of an entire capture scene. +1 >>> 3) Update section 6.2 on Capture scenes to reflect the above intents. >>> Changes proposals are: >>> - Section 6.2 2nd paragraph: >>> "A capture scene is a structure representing the <> scene that is >>> captured by a collection of<>capture devices. A >>> capture >>> scene..." >> >>> - Section 6.2 3rd paragraph: >>> "A provider may advertise multiple capture scenes or just a single >>> capture scene.<>> provider.>> >>> A media provider might typically use one capture >>> scene for main participant media and another capture scene for a >>> computer generated presentation...." +1 >>> 4) The framework uses the terms "media provider" and "provider". We >>> probably should be consistent in the use of the term throughout the >>> framework. +1 >> 3. Prioritisation >> ----------------- >> There was some discussion regarding whether any prioritization could be >> assumed from the order of captures (or any other element) in the structures >> in the framework. I think it was agreed that the framework didn't consider >> this. I think it should be clarified in the framework that no prioritisation >> is assumed. +1 (And then we put in a priority attribute to provide a mechanism for *explicit* prioritization.) >> 4. Captures in more than one capture scene entry >> ------------------------------------------------ >> The framework doesn't explicitly state that the same capture can be in more >> than one capture scene entry. The examples seem to suggest only one capture >> scene entry at a time. I assume though that a capture may reside in multiple >> capture scene entries. Explicit text should be added for clarity. +1 It is my understanding that a cature *may* be present in more than one CSE. (But a capture may only be present in *one* *scene*.) >> 5. Are simultaneous set mandatory? >> ---------------------------------- >> Simultaneous sets are defined in the framework but there is no explicit text >> indicating whether they are mandatory or optional for the Advertiser to >> send. Consumer side procedures would need to align with being mandatory or >> optional. >> I proposed some "hybrid" behaviour which seemed to have some support, i.e. >> >> "For a particular media type the consumer should choose one capture scene >> entry. If the advertiser has provided a simultaneous transmission set, the >> consumer may choose individual captures taking in account any simultaneity >> requirements". >> >> This support may need to be confirmed. I didn't get the feeling that we reached consensus on this. Personally I liked the idea that the CSEs provide some implicit simultaneous set information. So it would be convenient for it not to be necessary to state the same information explicitly. But that isn't enough for more complex cases. >> 6. Sending a configure >> ---------------------- >> (See thread [clue] Sending a configure 13/12/2012) >> There is some confusion regarding autonomous sending of configure messages. >> In response to the comments I propose to add the following: >> "Once the consumer has received an advertisement it may change its >> configuration of the provider's encodings any number of times during the >> call in response to signalling or other event by sending a new configure >> message." I agree with the intent. And the wording isn't bad. I'm not entirely comfortable with that use of "encodings", but don't have a better suggestion at the moment. Thanks, Paul >> 7. Capture Attributes >> --------------------- >> I'll address the addition of capture attributes in another email. >> >> Framework editors, how to proceed to address the above items? > [MB] We actually need the WG to agree with the proposed changes before > the FW editors should make changes (that's the IETF model for WG > documents). > > Therefore, we really need CLUE WG participants to review this and > respond so the FW editors can make any necessary changes before the > draft deadline. [/MB] >> >> 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 Mark.Duckworth@polycom.com Tue Feb 12 06:57: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 845EF21F8AFE for ; Tue, 12 Feb 2013 06:57:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNohHMCat0sM for ; Tue, 12 Feb 2013 06:57:44 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 476EB21F8578 for ; Tue, 12 Feb 2013 06:57:44 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Tue, 12 Feb 2013 06:57:43 -0800 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Tue, 12 Feb 2013 06:57:39 -0800 Thread-Topic: Framework updates Thread-Index: Ac4IFtXAwFOEr8l3SBuJ9zfqXts+vwBF2RHw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A6103924E05B7@CRPMBOXPRD01.polycom.com> References: <51187E70.6020104@nteczone.com> In-Reply-To: <51187E70.6020104@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] Framework updates X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 14:57:45 -0000 Hi Christian, Thank you very much for the reminders and specific suggestions. I thought some of these items had already reached consensus on some of thes= e items, which are already included in our working draft for the next versi= on of the framework. I'll comment on each particular item below. Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Sunday, February 10, 2013 9:15 PM > To: clue@ietf.org > Cc: Duckworth, Mark > Subject: Framework updates >=20 > Given that the deadline for submissions for the Orlando coming I thought = I > spend some time going back through some threads on the framework. >=20 > During the discussions of the concepts of scene, capture scene, capture > scene entry etc. I think we came up with several places where the > framework should be updated. These weren't picked up in the v8 update of > the framework. I've outlined them below: >=20 > 1. MCU terminating CLUE > ----------------------- > (thread: MCU terminating CLUE, or passing through? was: Capture scene > clarifications) > There was some discussion whether it was assumed that MCUs passed > messages through or MCUs terminated the CLUE signalling. It appeared that > the people thought (Stephen W words): > "that it is the responsibility of an MCU to consolidate room informatio= n it > has received from receiving rooms and provide, based on its unified view, > sensible choices for things like the selection of Capture scenes." >=20 > I believe something like the above text should be added to the framework. [Duckworth, Mark] I agree that was always the intent, that the MCU termina= ted the CLUE signaling. We can add clarification as you suggested. > 2. Capture Scene Clarifications > ------------------------------- > I made some proposals to clarify the capture scene concept that appeared = to > be accepted by the Mark. See "Re: [clue] Capture scene clarifications > 2/12/2012". >=20 > > 1) Introduce a new definition for "Scene". The capture scene definitio= n > and > several places mention "scene" but there's no explanation. I propo= se > the > following definition to be added to section 3 of the draft: > > Scene: Represents an area where the capture devices are spatially rela= ted. > > Non-spatially related devices exist in different scenes. >=20 > > 2) Update the definition of "Capture scene entry" to make it clearer t= hat it > > represents an entire scene. Proposed text is: > > *Capture Scene Entry: a list of media captures of the same media type > > that together form one representation of an entire capture scene. >=20 > > 3) Update section 6.2 on Capture scenes to reflect the above intents. > > Changes proposals are: > > - Section 6.2 2nd paragraph: > > "A capture scene is a structure representing the <> scene that= is > > captured by a collection of<>capture devices. > A capture > > scene..." >=20 > > - Section 6.2 3rd paragraph: > > "A provider may advertise multiple capture scenes or just a single > > capture scene.< provider.>> > > A media provider might typically use one capture > > scene for main participant media and another capture scene for a > > computer generated presentation...." >=20 > > 4) The framework uses the terms "media provider" and "provider". We > > probably should be consistent in the use of the term throughout the > > framework. [Duckworth, Mark] based on email list discussion, I did not create a new de= finition for "scene", but I have these updated definitions: Capture Scene: a structure representing a spatial region containing one or = more Capture Devices, each capturing media representing a portion of the re= gion. The spatial region represented by a scene may or may not correspond t= o a real region in physical space, such as a room. A capture scene include= s attributes and one or more capture scene entries, with each entry includi= ng one or more media captures. Capture Scene Entry: a list of media captures of the same media type that t= ogether form one way to represent the entire capture scene. Do you think there is still a need to add a definition for "scene"? I did update section 6.2 to be more consistent with these new definitions. > 3. Prioritisation > ----------------- > There was some discussion regarding whether any prioritization could be > assumed from the order of captures (or any other element) in the structur= es > in the framework. I think it was agreed that the framework didn't conside= r > this. I think it should be clarified in the framework that no prioritisat= ion is > assumed. [Duckworth, Mark] agreed, and this is in the next version. > 4. Captures in more than one capture scene entry > ------------------------------------------------ > The framework doesn't explicitly state that the same capture can be in mo= re > than one capture scene entry. The examples seem to suggest only one > capture scene entry at a time. I assume though that a capture may reside = in > multiple capture scene entries. Explicit text should be added for clarity= . [Duckworth, Mark] agreed, and this is in the next version. > 5. Are simultaneous set mandatory? > ---------------------------------- > Simultaneous sets are defined in the framework but there is no explicit t= ext > indicating whether they are mandatory or optional for the Advertiser to > send. Consumer side procedures would need to align with being mandatory > or optional. > I proposed some "hybrid" behaviour which seemed to have some support, > i.e. >=20 > "For a particular media type the consumer should choose one capture scene > entry. If the advertiser has provided a simultaneous transmission set, th= e > consumer may choose individual captures taking in account any simultaneit= y > requirements". >=20 > This support may need to be confirmed. [Duckworth, Mark] based on our previous email list discussions, here is wha= t I have in the next version: A media provider optionally includes the simultaneous sets in its provider = advertisement. These simultaneous set constraints apply across all the cap= ture scenes in the advertisement. The simultaneous transmission sets MUST = allow all the media captures in any particular capture scene entry to be us= ed simultaneously. If an advertisement does not include Simultaneous Transmission Sets, then a= ll capture scenes can be provided simultaneously. If multiple capture scen= e entries are in a capture scene then the media consumer may choose at most= one capture scene entry per scene for each media type. If an advertisement includes multiple capture scene entries in a capture sc= ene then the consumer SHOULD choose one capture scene entry for each media = type, but may choose captures based on the Simultaneous Transmission Sets > 6. Sending a configure > ---------------------- > (See thread [clue] Sending a configure 13/12/2012) There is some confusio= n > regarding autonomous sending of configure messages. In response to the > comments I propose to add the following: > "Once the consumer has received an advertisement it may change its > configuration of the provider's encodings any number of times during the = call > in response to signalling or other event by sending a new configure > message." [Duckworth, Mark] The framework already says "The consumer is able to chang= e its configuration of the provider's encodings any number of times during = the call, either in response to a new capture advertisement from the provid= er or autonomously." We could add "by sending a new configure message" to= make it more clear. > 7. Capture Attributes > --------------------- > I'll address the addition of capture attributes in another email. >=20 > Framework editors, how to proceed to address the above items? >=20 > Regards, Christian >=20 >=20 >=20 From pkyzivat@alum.mit.edu Tue Feb 12 09:29: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 9211B21F8FDF for ; Tue, 12 Feb 2013 09:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=0.088, 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 3Vkcm9JHlSxI for ; Tue, 12 Feb 2013 09:29:15 -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 CD1CD21F8FD8 for ; Tue, 12 Feb 2013 09:29:14 -0800 (PST) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta05.westchester.pa.mail.comcast.net with comcast id zPqe1k0070SCNGk55VVEgj; Tue, 12 Feb 2013 17:29:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id zVVD1k00c3ZTu2S3VVVDcs; Tue, 12 Feb 2013 17:29:14 +0000 Message-ID: <511A7BE9.4080306@alum.mit.edu> Date: Tue, 12 Feb 2013 12:29:13 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: CLUE 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=1360690154; bh=6TIfPBrqSltrkMU93YTecy/iFS5329XP/MdPTTC0zSw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mpRkwH6VwmtlQYNQ3s3On2XmukbcmdbfXEq8J3lbTc1s8uGfjO1fySA5/9qugivhU H/rseLzAyW4J+iCgJR/TNgbVwDgUaRqYyo/3+MaO8WAsofV1Uhmoph5aCsrDXN9UAi bfcvHbcxW5eBsEnVi2ScPrwbgbHeG0L6pAFFt66z8S8exbsFvNRvx9aeGvXWGvz5/p 8LN2p3M36FWiEJ/NUGxfCC+3LwmHc1Avb78iExVhlUOICUmeQE4O5URzMCfOlhos6V GqYf+b4jvf56Jwc3rzsapPtfdKyEj1XXinaI0ydaNf9V6IsfvT3sFBkWUz7aXxo8vy ujE5x04aEBMog== Subject: [clue] 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, 12 Feb 2013 17:29:15 -0000 I'm working on an -02 version now, to be published in the next day or two. Thanks, Paul From mary.ietf.barnes@gmail.com Tue Feb 12 12:06: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 1171021F8DD6 for ; Tue, 12 Feb 2013 12:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 J4lAEURC77rW for ; Tue, 12 Feb 2013 12:06:32 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 034AF21F8DCF for ; Tue, 12 Feb 2013 12:06:28 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id b12so173591qca.4 for ; Tue, 12 Feb 2013 12:06:28 -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=1vd6y9+Q3kM+x4fStDnPBeapUQOBWgLUiS1BB2MzrqE=; b=pIw/yxFPc7aBfBoRDrSrWangdHV/6kbguAWPp5lUH08u8fsi98Vx3E1Z/wTqFxi6xj l1DmNsajwW9/yGBadrdxDyNQ2K1yUZMN+QdDwoaPjs4UbK9Q0ZbW4wyXZv1M9kFjcDvN eJRBI8RciduFNCwI+XoCSPRs5D3Lbr2066O/gfRnV+cjFYgX6U5dFW3fb022aFQecdee O/UJJiBcIfxTzAAFFWXU6KcMbZNXE0uPCwqqGpzW/sMScKKqKM+swtf3dVCgSWmlK8/3 ckd5eLX1Vh7A8niHnQHwuucjLqqYMwZMdk/8TXWwzz52Dras5Ch9IwU1ZbkK9fZ4VHzq r0Xg== MIME-Version: 1.0 X-Received: by 10.224.216.65 with SMTP id hh1mr7127903qab.43.1360699588459; Tue, 12 Feb 2013 12:06:28 -0800 (PST) Received: by 10.49.131.199 with HTTP; Tue, 12 Feb 2013 12:06:28 -0800 (PST) Date: Tue, 12 Feb 2013 14:06:28 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Minutes: Design Team meeting today (Feb. 11th) @ 10am Central X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 20:06:33 -0000 Hi all, Thanks for the great attendance on the call and the efficient use of time (33 minutes;) Below are my notes and action items captured yesterday. Attendees (in random order): Mary Barnes, Paul Kyzivat, Andy Pepperell, Jonathan Lennox, Rob Hansen, Simon Pietro-Romano, Roberta Presta, Roni Even and Stephan Wenger Recording: https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=10397547&rKey=ccd6b3f68b6c2ec8 0) We had some discussion of the IETF-86 agenda. - Jonathan noted that CLUE is opposite RMCAT. [Action: Mary. Follow-up with ADs on re-arranging agenda. Status: - It was noted that MMUSIC looks to have about 4 hours of meeting time, which is good. Mary suggested Jonathan/Roni request agenda time for draft-even-mmusic-multiple-streams-01.txt. Even though it's not fully baked, CLUE really needs to start feeding our requirements and solution proposals into that WG. 1) Feedback on RTCWEB/MMUSIC interim meeting. - A sense of the room was taken with regards to whether the work in MMUSIC should consider CLUE requirements. The results indicated a fairly rough split, so the way forward at this time in MMUSIC is for CLUE requirements to be considered. [Action: CLUE WG. Review the requirements in this presentation and decide whether they suffice or whether we have additional requirements. http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-10.pdf] AFAIK, they are not yet in draft form. - There remains a fair amount of debate with regards to the basic signaling model. Jonathan suggested that what CLUE might need is similar to Cullen's proposal B in the presentation above. - Jonathan noted that the big relation is with regards to the RTP mapping as discussed in draft-even-clue-rtp-mapping. - We discussed whether the RTCWEB SDP usage really needs to match the CLUE SDP usage. It was noted that an interworking function is necessary regardless as it's clear that the RTCWEB SDP usage will not likely interact well with a "legacy" SIP client. - Terminology: It was noted that RTCWEB is using different terminology with regards to a model for multi-stream/video conferencing. We *really* need to agree on some terminology in the cases where we really are talking about the same things. This came up in Justin's presentation: http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-7.pdf [Action: Mary. Contact Justin with regards to working on common terminology. Note: this re-enforces the need for the CLUE FW document to be less solution specific and to have a more high level description of the CLUE FW model. ] - Note: one other important item that wasn't mentioned on the call is that there was a fair amount of discussion with regards to the data channel signaling. Since CLUE was planning to piggyback on the solution for SCTP, we need to pay attention to the issues/solution proposals that RTCWEB is discussing: http://www.ietf.org/proceedings/interim/2013/02/05/rtcweb/slides/slides-interim-2013-rtcweb-1-9.pdf 2) Plans and document status for IETF-86: - FW. Stephan noted that a major clean-up is underway. At a minimum they will mark what should go in other docs and remove what is already in other documents. It would be good if any changes based on Christian's comments could be incorporated: http://www.ietf.org/mail-archive/web/clue/current/msg02329.html [Action: FW authors and WG participants. Review and respond to these comments so we can get consensus on what to incorporate into the revised FW document. - Signaling: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling/ Paul has made a first pass and Roberta has added some material. This really needs to be beefed up before the meeting. Rob noted that he has content to add. Paul also does. [Note: he has the current dibs on the document]. The model should be that folks send an email to the list that they are currently editing. I would like to suggest that once the doc is claimed that the changes are submitted within 24 hours (and no later than 48) so folks have time to get their changes in. Folks can create their text offline and then cut and paste into appropriate sections when they get the document. It is a working document and folks should add relevant Editor's notes and comments/questions (it would be useful to put these in brackets or use some notation to highlight these). - @IETF-86. Since we have some time between the CLUE WG sessions (Monday afternoon - Thursday morning), it would be good to get a room and schedule time for a CLUE DT meeting to ensure we make the most of the f2f time. [Action: WG participants/contributors. Send conflicts to chairs so we can find a day/time.] From john@jlc.net Tue Feb 12 15:02: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 CAF7221F8B64 for ; Tue, 12 Feb 2013 15:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.159 X-Spam-Level: X-Spam-Status: No, score=-106.159 tagged_above=-999 required=5 tests=[AWL=0.441, 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 DD7W6is+QmBd for ; Tue, 12 Feb 2013 15:02:45 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id D0DAE21F88CC for ; Tue, 12 Feb 2013 15:02:44 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1DF0533CC0; Tue, 12 Feb 2013 18:02:44 -0500 (EST) Date: Tue, 12 Feb 2013 18:02:44 -0500 From: John Leslie To: "Duckworth, Mark" , "clue@ietf.org" Message-ID: <20130212230244.GD44670@verdi> References: <51187E70.6020104@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103924E05B7@CRPMBOXPRD01.polycom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6103924E05B7@CRPMBOXPRD01.polycom.com> User-Agent: Mutt/1.4.1i Subject: Re: [clue] Framework updates X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 23:02:45 -0000 Duckworth, Mark wrote: > To: Christian Groves > >> 2. Capture Scene Clarifications >> ------------------------------- >> I made some proposals to clarify the capture scene concept that appeared to >> be accepted by the Mark. See "Re: [clue] Capture scene clarifications >> 2/12/2012". >> >>> 1) Introduce a new definition for "Scene". The capture scene definition >>> and several places mention "scene" but there's no explanation. I propose >>> the following definition to be added to section 3 of the draft: >> >>> Scene: Represents an area where the capture devices are spatially related. >>> Non-spatially related devices exist in different scenes. >>... > > based on email list discussion, I did not create a new definition for > "scene", but I have these updated definitions: > > Capture Scene: a structure representing a spatial region containing one > or more Capture Devices, each capturing media representing a portion of > the region. The spatial region represented by a scene may or may not > correspond to a real region in physical space, such as a room. A capture > scene includes attributes and one or more capture scene entries, with > each entry including one or more media captures. > > Capture Scene Entry: a list of media captures of the same media type > that together form one way to represent the entire capture scene. > > Do you think there is still a need to add a definition for "scene"? Generally, replacing "scene" with "region" where it appears alone is sufficient: but there are quite a few cases. For example: 4. Overview of the Framework/Model A provider organizes its media captures that represent the same _scene_ into capture scenes. 6.2. Capture Scene A capture scene is a structure representing the _scene_ that is captured by a collection of capture devices. ... When a provider advertises a capture scene with multiple entries, it is essentially signaling that there are multiple representations of the same _scene_ available. ... The inclusion of the audio capture in the same capture scene indicates that AC0 is associated with those video captures, meaning it comes from the same _scene_. 6.2.1. Capture scene attributes Area of _Scene_ attribute: The area of _scene_ attribute for a capture scene has the same format as the area of capture attribute for a media capture. If the provider does not specify the area of _scene_, but does specify areas of capture, then the consumer may assume the area of _scene_ is greater than or equal to the outer extents of the individual areas of capture. ... Scale attribute: An optional attribute indicating if the numbers used for area of _scene_, area of capture and point of capture are in terms of millimeters, unknown scale factor, or not any scale, as described in Section 5. 6.2.2. Capture scene entry attributes _Scene_-switch-policy: {site-switch, segment-switch}... 11.1. Three screen endpoint media provider Capture Scenes: The following table represents the capture scenes for this provider. Recall that a capture scene is composed of alternative capture scene entries covering the same _scene_. -- John Leslie From mary.ietf.barnes@gmail.com Tue Feb 12 16:56: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 BEF5121F8949 for ; Tue, 12 Feb 2013 16:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 2CkdMMqAGMQ3 for ; Tue, 12 Feb 2013 16:56:31 -0800 (PST) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA0C21F893E for ; Tue, 12 Feb 2013 16:56:31 -0800 (PST) Received: by mail-qe0-f54.google.com with SMTP id 1so317435qeb.13 for ; Tue, 12 Feb 2013 16:56:30 -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=TMxjQ5fDuzcw5jrVVAWBLZtT/WFm5QqKVvM4c09/FEw=; b=teVrGMKQrOMBFOpZBTY6nPbyj3on2g0FvLE2eqYDXiyU9eOFd7iVA77sgAxjvn7J2E 0ka+mtymONk/tlJhJc1Cn7zbEQoMCXAHYctCamg4sHDCXPWnG/uLjg1WS68HLMbYvUz4 GsMm73hzmZurJlt7nMSQfyPEvEozNnxi7LMQx0VgzDBF8+U6gMRXXuYmBX6QHEyla2EA Ng7vPuxnGqSxAnZSXdtL+SUVCEcks1mbaXzYMM5GGmPQnxTa5kaV84ShmtFsC2a0Mj8E jTab3J61zAszZI8UveNP2f0/xgbEEYGaNRG6ZT3B1VNpa7QxGihxHUM6LwLdwUkaSebg 4kWw== MIME-Version: 1.0 X-Received: by 10.229.201.200 with SMTP id fb8mr1829253qcb.122.1360716990556; Tue, 12 Feb 2013 16:56:30 -0800 (PST) Received: by 10.49.131.199 with HTTP; Tue, 12 Feb 2013 16:56:30 -0800 (PST) In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> Date: Tue, 12 Feb 2013 18:56:30 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Cc: Jonathan Lennox Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 00:56:31 -0000 Hi all, We would like to determine consensus for adopting this document as the basis for a CLUE WG deliverable. As usual, accepting the document as a WG document does not mean that there is not a need for additional changes, it just means this is a good starting point. If folks could please respond "Yes" or "No" as to whether you agree with adopting this document as a WG document no later than Thursday, Feb. 14th, 2013 @ 5pm Pacific. Thanks, Mary. On Fri, Feb 1, 2013 at 4:27 AM, Roni Even wrote: > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Friday, February 01, 2013 12:24 PM > To: Roni Even > Cc: jonathan@vidyo.com > Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt > > A new version of I-D, draft-even-clue-rtp-mapping-05.txt > has been successfully submitted by Roni Even and posted to the > IETF repository. > > Filename: draft-even-clue-rtp-mapping > Revision: 05 > Title: Mapping RTP streams to CLUE media captures > Creation date: 2013-02-01 > WG ID: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-mapping-05.txt > Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping > Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 > Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp-mapping-05 > > Abstract: > This document describes mechanisms and recommended practice for > mapping RTP media streams defined in SDP to CLUE media captures. > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stewe@stewe.org Tue Feb 12 17:50: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 EB44621F8A6B for ; Tue, 12 Feb 2013 17:50:43 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwW-Sk7F85yr for ; Tue, 12 Feb 2013 17:50:42 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7153C21F8A4E for ; Tue, 12 Feb 2013 17:50:42 -0800 (PST) Received: from mail56-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Feb 2013 01:50:41 +0000 Received: from mail56-ch1 (localhost [127.0.0.1]) by mail56-ch1-R.bigfish.com (Postfix) with ESMTP id 70A81160203; Wed, 13 Feb 2013 01:50:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT004.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zz98dI9371I936eI542I1432I4015I14ffIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail56-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT004.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail56-ch1 (localhost.localdomain [127.0.0.1]) by mail56-ch1 (MessageSwitch) id 1360720240287696_17761; Wed, 13 Feb 2013 01:50:40 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail56-ch1.bigfish.com (Postfix) with ESMTP id 3A1E560591; Wed, 13 Feb 2013 01:50:40 +0000 (UTC) Received: from BL2PRD0710HT004.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Feb 2013 01:50:39 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.145]) by BL2PRD0710HT004.namprd07.prod.outlook.com ([10.255.102.39]) with mapi id 14.16.0263.000; Wed, 13 Feb 2013 01:50:39 +0000 From: Stephan Wenger To: Mary Barnes , CLUE Thread-Topic: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt Thread-Index: AQHOAGZFhqkzxGtQfkOnEc8pSy+fOphkzFhbgBI8xgCAAA8XgA== Date: Wed, 13 Feb 2013 01:50:38 +0000 Message-ID: References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.202.147.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: Jonathan Lennox Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 01:50:44 -0000 Yes. Stephan -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: 12 February, 2013 16:57 To: CLUE Cc: Jonathan Lennox Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-ma= pping-05.txt Hi all, We would like to determine consensus for adopting this document as the basi= s for a CLUE WG deliverable. As usual, accepting the document as a WG docu= ment does not mean that there is not a need for additional changes, it just= means this is a good starting point. If folks could please respond "Yes" or "No" as to whether you agree with ad= opting this document as a WG document no later than Thursday, Feb. 14th, 20= 13 @ 5pm Pacific. Thanks, Mary. On Fri, Feb 1, 2013 at 4:27 AM, Roni Even wro= te: > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Friday, February 01, 2013 12:24 PM > To: Roni Even > Cc: jonathan@vidyo.com > Subject: New Version Notification for=20 > draft-even-clue-rtp-mapping-05.txt > > A new version of I-D, draft-even-clue-rtp-mapping-05.txt > has been successfully submitted by Roni Even and posted to the IETF=20 > repository. > > Filename: draft-even-clue-rtp-mapping > Revision: 05 > Title: Mapping RTP streams to CLUE media captures > Creation date: 2013-02-01 > WG ID: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-= mapping-05.txt > Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapp= ing > Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-0= 5 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-clue-rtp-m= apping-05 > > Abstract: > This document describes mechanisms and recommended practice for > mapping RTP media streams defined in SDP to CLUE media captures. > > > > > The IETF Secretariat > _______________________________________________ > 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 Tue Feb 12 17:53:35 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 D87BD21F86F6 for ; Tue, 12 Feb 2013 17:53:35 -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 9a52u+vuClQS for ; Tue, 12 Feb 2013 17:53:35 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id BD18E21F86E8 for ; Tue, 12 Feb 2013 17:53:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYBAIPxGlF20cdH/2dsb2JhbAANN4N5vQ6DEgEBAQQBAQE1GxsJARELEQQBAQEJFg8JAwIBAgEVJwEIEwYCAQEFiBAFrFWTKI5bgyoDl0GSUA Received: from ppp118-209-199-71.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.199.71]) by ipmail06.adl6.internode.on.net with ESMTP; 13 Feb 2013 12:23:33 +1030 Message-ID: <511AF21A.3080001@nteczone.com> Date: Wed, 13 Feb 2013 12:53:30 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 01:53:36 -0000 Yes Regards, Christian On 13/02/2013 11:56 AM, Mary Barnes wrote: > Hi all, > > We would like to determine consensus for adopting this document as the > basis for a CLUE WG deliverable. As usual, accepting the document as > a WG document does not mean that there is not a need for additional > changes, it just means this is a good starting point. > > If folks could please respond "Yes" or "No" as to whether you agree > with adopting this document as a WG document no later than Thursday, > Feb. 14th, 2013 @ 5pm Pacific. > > Thanks, > Mary. > > On Fri, Feb 1, 2013 at 4:27 AM, Roni Even wrote: >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Friday, February 01, 2013 12:24 PM >> To: Roni Even >> Cc: jonathan@vidyo.com >> Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt >> >> A new version of I-D, draft-even-clue-rtp-mapping-05.txt >> has been successfully submitted by Roni Even and posted to the >> IETF repository. >> >> Filename: draft-even-clue-rtp-mapping >> Revision: 05 >> Title: Mapping RTP streams to CLUE media captures >> Creation date: 2013-02-01 >> WG ID: Individual Submission >> Number of pages: 19 >> URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-mapping-05.txt >> Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping >> Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp-mapping-05 >> >> Abstract: >> This document describes mechanisms and recommended practice for >> mapping RTP media streams defined in SDP to CLUE media captures. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> 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 Tue Feb 12 18:16: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 61C6921F8AA0 for ; Tue, 12 Feb 2013 18:16:31 -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 QY2-2lyUsJfq for ; Tue, 12 Feb 2013 18:16:30 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id E4E8821F8A8F for ; Tue, 12 Feb 2013 18:16:29 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAD3GlF20cdH/2dsb2JhbAANN70Jg32DEgEBAQMBOBslARALGAkMCg8JAwIBAgFFBg0BBwEBFYdzrGmTJ40uC4EWgzYDkjCXYYFe Received: from ppp118-209-199-71.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.199.71]) by ipmail06.adl6.internode.on.net with ESMTP; 13 Feb 2013 12:46:28 +1030 Message-ID: <511AF778.5060209@nteczone.com> Date: Wed, 13 Feb 2013 13:16:24 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Duckworth, Mark" References: <51187E70.6020104@nteczone.com> <44C6B6B2D0CF424AA90B6055548D7A6103924E05B7@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A6103924E05B7@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Framework updates X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 02:16:31 -0000 Hello Mark, Please see my responses below. Regards, Christian On 13/02/2013 1:57 AM, Duckworth, Mark wrote: > Hi Christian, > > Thank you very much for the reminders and specific suggestions. > I thought some of these items had already reached consensus on some of these items, which are already included in our working draft for the next version of the framework. > > I'll comment on each particular item below. > > Mark > > ..snip.. >> 2. Capture Scene Clarifications >> ------------------------------- >> I made some proposals to clarify the capture scene concept that appeared to >> be accepted by the Mark. See "Re: [clue] Capture scene clarifications >> 2/12/2012". >> >> > 1) Introduce a new definition for "Scene". The capture scene definition >> and > several places mention "scene" but there's no explanation. I propose >> the > following definition to be added to section 3 of the draft: >> > Scene: Represents an area where the capture devices are spatially related. >> > Non-spatially related devices exist in different scenes. >> >> > 2) Update the definition of "Capture scene entry" to make it clearer that it >>> represents an entire scene. Proposed text is: >> > *Capture Scene Entry: a list of media captures of the same media type >> > that together form one representation of an entire capture scene. >> >> > 3) Update section 6.2 on Capture scenes to reflect the above intents. >> > Changes proposals are: >> > - Section 6.2 2nd paragraph: >> > "A capture scene is a structure representing the <> scene that is >> > captured by a collection of<>capture devices. >> A capture >> > scene..." >> >> > - Section 6.2 3rd paragraph: >> > "A provider may advertise multiple capture scenes or just a single >> > capture scene.<> provider.>> >> > A media provider might typically use one capture >> > scene for main participant media and another capture scene for a >> > computer generated presentation...." >> >> > 4) The framework uses the terms "media provider" and "provider". We > >> probably should be consistent in the use of the term throughout the > >> framework. > [Duckworth, Mark] based on email list discussion, I did not create a new definition for "scene", but I have these updated definitions: > > Capture Scene: a structure representing a spatial region containing one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a scene may or may not correspond to a real region in physical space, such as a room. A capture scene includes attributes and one or more capture scene entries, with each entry including one or more media captures. > > Capture Scene Entry: a list of media captures of the same media type that together form one way to represent the entire capture scene. > > Do you think there is still a need to add a definition for "scene"? > > I did update section 6.2 to be more consistent with these new definitions. [CNG] I agree with John's response on this. We don't need to define it if it isn't used. I.e. either use "region" or "capture scene" as appropriate. > ..snip.. > >> 5. Are simultaneous set mandatory? >> ---------------------------------- >> Simultaneous sets are defined in the framework but there is no explicit text >> indicating whether they are mandatory or optional for the Advertiser to >> send. Consumer side procedures would need to align with being mandatory >> or optional. >> I proposed some "hybrid" behaviour which seemed to have some support, >> i.e. >> >> "For a particular media type the consumer should choose one capture scene >> entry. If the advertiser has provided a simultaneous transmission set, the >> consumer may choose individual captures taking in account any simultaneity >> requirements". >> >> This support may need to be confirmed. > [Duckworth, Mark] based on our previous email list discussions, here is what I have in the next version: > > A media provider optionally includes the simultaneous sets in its provider advertisement. These simultaneous set constraints apply across all the capture scenes in the advertisement. The simultaneous transmission sets MUST allow all the media captures in any particular capture scene entry to be used simultaneously. > > If an advertisement does not include Simultaneous Transmission Sets, then all capture scenes can be provided simultaneously. If multiple capture scene entries are in a capture scene then the media consumer may choose at most one capture scene entry per scene for each media type. [CNG] i'd prefer to use something other than "may choose" because to me at least it gives the option to do something else. Also need to say "per scene for each media type." > > If an advertisement includes multiple capture scene entries in a capture scene then the consumer SHOULD choose one capture scene entry for each media type, but may choose captures based on the Simultaneous Transmission Sets. [CNG] I suggest .... but may choose captures based...> Other wise OK. > >> 6. Sending a configure >> ---------------------- >> (See thread [clue] Sending a configure 13/12/2012) There is some confusion >> regarding autonomous sending of configure messages. In response to the >> comments I propose to add the following: >> "Once the consumer has received an advertisement it may change its >> configuration of the provider's encodings any number of times during the call >> in response to signalling or other event by sending a new configure >> message." > [Duckworth, Mark] The framework already says "The consumer is able to change its configuration of the provider's encodings any number of times during the call, either in response to a new capture advertisement from the provider or autonomously." We could add "by sending a new configure message" to make it more clear. [CNG] How about? "The consumer is able to change its configuration any number of time during a CLUE channel association. Any change in configuration should be within the bounds of the information received in a prior Advertisement. The change may be in response to a newly received Advertisement or a local event. The change is communicated from to the provider in the form of a new configure message." Rather than one long sentence I've proposed to break each "requirement" into a separate sentence. I've also changed "call" to "CLUE channel association". This may not be the best formulation but I think its important to separate the two things. A CLUE channel may or may not be up for the life of a multimedia session. A consumer can only update CLUE information during whilst the CLUE channel is established. > >> 7. Capture Attributes >> --------------------- >> I'll address the addition of capture attributes in another email. >> >> Framework editors, how to proceed to address the above items? >> >> Regards, Christian >> >> >> > From rohanse2@cisco.com Wed Feb 13 08:27: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 C009721F88E5 for ; Wed, 13 Feb 2013 08:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXL0F6ba+KaQ for ; Wed, 13 Feb 2013 08:27:56 -0800 (PST) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id A8E2A21F8881 for ; Wed, 13 Feb 2013 08:27:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2122; q=dns/txt; s=iport; t=1360772869; x=1361982469; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=d7nW5GTzQEH528BBTS1+d/44+oD39EwIXd8nuYpZKDY=; b=gHDywOf2QRvIsV0kFcjMD21YN+sqVm6U2rZrttGILRdc23LROTLkcXiK o1auL1ItlTWu8ex5N7tXKt2bgZXxo/NnKG/U6onMBVNU4V9XlHD3BaRTk gUkQUOFDHoVsQ0JnAHUMuVtqwvAEdrEhvG3KEnlaknAWOnHiNrPQTz3cb M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFy+G1GQ/khR/2dsb2JhbABFg3q8dBZzgh8BAQEEAQEBNTYJARELEQQBAQEJFg8JAwIBAgEVJwEIEwYCAQEFiAkHBb5wjlqDKgOWJIEdhFSKYoMG X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="11771791" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 13 Feb 2013 16:27:48 +0000 Received: from [10.47.196.105] ([10.47.196.105]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1DGRmcv007707 for ; Wed, 13 Feb 2013 16:27:48 GMT Message-ID: <511BBF20.1010506@cisco.com> Date: Wed, 13 Feb 2013 16:28:16 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 16:27:56 -0000 Yes, Rob On 13/02/2013 00:56, Mary Barnes wrote: > Hi all, > > We would like to determine consensus for adopting this document as the > basis for a CLUE WG deliverable. As usual, accepting the document as > a WG document does not mean that there is not a need for additional > changes, it just means this is a good starting point. > > If folks could please respond "Yes" or "No" as to whether you agree > with adopting this document as a WG document no later than Thursday, > Feb. 14th, 2013 @ 5pm Pacific. > > Thanks, > Mary. > > On Fri, Feb 1, 2013 at 4:27 AM, Roni Even wrote: >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Friday, February 01, 2013 12:24 PM >> To: Roni Even >> Cc: jonathan@vidyo.com >> Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt >> >> A new version of I-D, draft-even-clue-rtp-mapping-05.txt >> has been successfully submitted by Roni Even and posted to the >> IETF repository. >> >> Filename: draft-even-clue-rtp-mapping >> Revision: 05 >> Title: Mapping RTP streams to CLUE media captures >> Creation date: 2013-02-01 >> WG ID: Individual Submission >> Number of pages: 19 >> URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-mapping-05.txt >> Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping >> Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp-mapping-05 >> >> Abstract: >> This document describes mechanisms and recommended practice for >> mapping RTP media streams defined in SDP to CLUE media captures. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> 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 Feb 13 11:10: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 E650521F84BF for ; Wed, 13 Feb 2013 11:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=0.137, 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 ycx8cuRHJ9fV for ; Wed, 13 Feb 2013 11:10:00 -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 32F3F21F84C0 for ; Wed, 13 Feb 2013 11:09:57 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id znyA1k00B1ap0As53v9nYK; Wed, 13 Feb 2013 19:09:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id zv9n1k00R3ZTu2S3iv9ntd; Wed, 13 Feb 2013 19:09:47 +0000 Message-ID: <511BE4FB.8040304@alum.mit.edu> Date: Wed, 13 Feb 2013 14:09:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: CLUE References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.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=1360782587; bh=YRf/caVIjgGN07BiTabdMi+67IiOvmpvKsBj4s1IoYQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ph5C7qZnip7lLxTiuidQAYby1DfXzEjiYcebXwrGkz8r2ve5lRcY+bX22X/bPvwwB 7I5V6hLhcpRtVPIbh6hrfEjbg9ol1qoO/ozMpHR52v+6pPe3bApojaY2sIaoltBz7o JCUoHPSKFT+UkILHViN2PzoyWiBuveNf07h56Zqzlt/lZvrecgFSRQhoOgPZqdHSaO yghAOwSMIfK8tkcsz+QFIVHLO18TQzNOE5Mccl6K25OCZi24lrvOOD+pHyPBKVtTux cIgaWnyBFuxXluUnoJ5Oyg4BCz6fsL+628qBOsZdZ1HW0kDM4aHAgEAtOIkw3LgBHf hz+dMdYI4YRUg== Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 19:10:01 -0000 yes (as individual) Paul On 2/12/13 7:56 PM, Mary Barnes wrote: > Hi all, > > We would like to determine consensus for adopting this document as the > basis for a CLUE WG deliverable. As usual, accepting the document as > a WG document does not mean that there is not a need for additional > changes, it just means this is a good starting point. > > If folks could please respond "Yes" or "No" as to whether you agree > with adopting this document as a WG document no later than Thursday, > Feb. 14th, 2013 @ 5pm Pacific. > > Thanks, > Mary. > > On Fri, Feb 1, 2013 at 4:27 AM, Roni Even wrote: >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Friday, February 01, 2013 12:24 PM >> To: Roni Even >> Cc: jonathan@vidyo.com >> Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt >> >> A new version of I-D, draft-even-clue-rtp-mapping-05.txt >> has been successfully submitted by Roni Even and posted to the >> IETF repository. >> >> Filename: draft-even-clue-rtp-mapping >> Revision: 05 >> Title: Mapping RTP streams to CLUE media captures >> Creation date: 2013-02-01 >> WG ID: Individual Submission >> Number of pages: 19 >> URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-mapping-05.txt >> Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping >> Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp-mapping-05 >> >> Abstract: >> This document describes mechanisms and recommended practice for >> mapping RTP media streams defined in SDP to CLUE media captures. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From espeberg@cisco.com Wed Feb 13 11:17: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 EC2871F0D0A for ; Wed, 13 Feb 2013 11:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHjjIjIAd9bg for ; Wed, 13 Feb 2013 11:17:30 -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 5B2AA1F0D0B for ; Wed, 13 Feb 2013 11:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2321; q=dns/txt; s=iport; t=1360783050; x=1361992650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=XkbePuBzF6/9xTEskX7AAwhOPDe3keaBFWj+4JYaqzc=; b=dI1+m61KLFgR44EUr+VIx1wi/koA0ITE2bKvs+5h3lpYRaTco76Yu3dO FeAyOtxKTcu96a7Cn7cOUzMpD5VKcr2w/GsSw96JpPAd6dCNiRusxPKRi nAn9ig4J+yLlSx3I8KaHLg0ipAQMcm3Z2x01V63t4HuF44/xJugVzWgqk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAHTmG1GtJV2c/2dsb2JhbABFg3q8dBZzgh8BAQEEAQEBNzQJAgwEAgEIEQQBAQEKFAkHJwsUCAEIAgQBDQUIAYgJBwW/UJEjYQOXQY82gwaCJw X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176758991" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 13 Feb 2013 19:17:29 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1DJHTx0029264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 19:17:29 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.247]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 13:17:29 -0600 From: "Espen Berger (espeberg)" To: Mary Barnes , CLUE Thread-Topic: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt Thread-Index: AQHOAGZFhqkzxGtQfkOnEc8pSy+fOphkzFhbgBKhWwCAAM7wgA== Date: Wed, 13 Feb 2013 19:17:28 +0000 Message-ID: References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.83.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jonathan Lennox Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 19:17:32 -0000 Yes -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: 13. februar 2013 01:57 To: CLUE Cc: Jonathan Lennox Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-ma= pping-05.txt Hi all, We would like to determine consensus for adopting this document as the basi= s for a CLUE WG deliverable. As usual, accepting the document as a WG docu= ment does not mean that there is not a need for additional changes, it just= means this is a good starting point. If folks could please respond "Yes" or "No" as to whether you agree with ad= opting this document as a WG document no later than Thursday, Feb. 14th, 20= 13 @ 5pm Pacific. Thanks, Mary. On Fri, Feb 1, 2013 at 4:27 AM, Roni Even wro= te: > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Friday, February 01, 2013 12:24 PM > To: Roni Even > Cc: jonathan@vidyo.com > Subject: New Version Notification for=20 > draft-even-clue-rtp-mapping-05.txt > > A new version of I-D, draft-even-clue-rtp-mapping-05.txt > has been successfully submitted by Roni Even and posted to the IETF=20 > repository. > > Filename: draft-even-clue-rtp-mapping > Revision: 05 > Title: Mapping RTP streams to CLUE media captures > Creation date: 2013-02-01 > WG ID: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-= mapping-05.txt > Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapp= ing > Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-0= 5 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-clue-rtp-m= apping-05 > > Abstract: > This document describes mechanisms and recommended practice for > mapping RTP media streams defined in SDP to CLUE media captures. > > > > > The IETF Secretariat > _______________________________________________ > 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 Wed Feb 13 12:00: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 5F6C121E8084 for ; Wed, 13 Feb 2013 12:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.384 X-Spam-Level: X-Spam-Status: No, score=-99.384 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, USER_IN_WHITELIST=-100] 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 ZHPAsgWxoC3v for ; Wed, 13 Feb 2013 12:00:38 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3BC21E8094 for ; Wed, 13 Feb 2013 12:00:37 -0800 (PST) Received: from [1.130.112.70] ([94.163.115.130]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r1DK0TYA030767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 13 Feb 2013 21:00:30 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YIA4DTLRN36Q6HA8UGJMDHOSB8ZHI0" From: Simon Pietro Romano Date: Wed, 13 Feb 2013 21:00:26 +0100 To: "Espen Berger (espeberg)" , Mary Barnes , CLUE Message-ID: <3309d3d7-69e2-4ad5-a50c-c807612ff419@email.android.com> Cc: Jonathan Lennox Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 20:00:40 -0000 ------YIA4DTLRN36Q6HA8UGJMDHOSB8ZHI0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Yes Simon "Espen Berger (espeberg)" ha scritto: >Yes > >-Espen > > >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Mary Barnes >Sent: 13. februar 2013 01:57 >To: CLUE >Cc: Jonathan Lennox >Subject: Re: [clue] FW: New Version Notification for >draft-even-clue-rtp-mapping-05.txt > >Hi all, > >We would like to determine consensus for adopting this document as the >basis for a CLUE WG deliverable. As usual, accepting the document as a >WG document does not mean that there is not a need for additional >changes, it just means this is a good starting point. > >If folks could please respond "Yes" or "No" as to whether you agree >with adopting this document as a WG document no later than Thursday, >Feb. 14th, 2013 @ 5pm Pacific. > >Thanks, >Mary. > >On Fri, Feb 1, 2013 at 4:27 AM, Roni Even >wrote: >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Friday, February 01, 2013 12:24 PM >> To: Roni Even >> Cc: jonathan@vidyo.com >> Subject: New Version Notification for >> draft-even-clue-rtp-mapping-05.txt >> >> A new version of I-D, draft-even-clue-rtp-mapping-05.txt >> has been successfully submitted by Roni Even and posted to the IETF >> repository. >> >> Filename: draft-even-clue-rtp-mapping >> Revision: 05 >> Title: Mapping RTP streams to CLUE media captures >> Creation date: 2013-02-01 >> WG ID: Individual Submission >> Number of pages: 19 >> URL: >http://www.ietf.org/internet-drafts/draft-even-clue-rtp-mapping-05.txt >> Status: >http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping >> Htmlized: >http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 >> Diff: >http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp-mapping-05 >> >> Abstract: >> This document describes mechanisms and recommended practice for >> mapping RTP media streams defined in SDP to CLUE media captures. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> 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 ------YIA4DTLRN36Q6HA8UGJMDHOSB8ZHI0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yes

Simon

"Espen Berger (espeberg)" <espeberg@cisco.com> ha scritto:
Yes

-Espen 


-----Original Message-----
From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 13. februar 2013 01:57
To: CLUE
Cc: Jonathan Lennox
Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt

Hi all,

We would like to determine consensus for adopting this document as the basis for a CLUE WG deliverable.  As usual, accepting the document as a WG document does not mean that there is not a need for additional changes, it just means this is a good starting point.

If folks could please respond "Yes" or "No" as to whether you agree with adopting this document as a WG document no later than Thursday, Feb. 14th, 2013 @ 5pm Pacific.

Thanks,
Mary.

On Fri, Feb 1, 2013 at 4:27 AM, Roni Even
<roni.even@mail01.huawei.com> wrote:


From: internet-drafts@ietf.org [internet-drafts@ietf.org]
Sent: Friday, February 01, 2013 12:24 PM
To: Roni Even
Cc: jonathan@vidyo.com
Subject: New Version Notification for 
draft-even-clue-rtp-mapping-05.txt

A new version of I-D, draft-even-clue-rtp-mapping-05.txt
has been successfully submitted by Roni Even and posted to the IETF 
repository.

Filename:        draft-even-clue-rtp-mapping
Revision:        05
Title:           Mapping RTP streams to CLUE media captures
Creation date:   2013-02-01
WG ID:           Individual Submission
Number of pages: 19
URL:             http://www.ietf.org/internet-drafts/draft-even-clue-rtp-mapping-05.txt
Status:          http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping
Htmlized:        http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp-mapping-05

Abstract:
This document describes mechanisms and recommended practice for
mapping RTP media streams defined in SDP to CLUE media captures.




The IETF Secretariat

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

------YIA4DTLRN36Q6HA8UGJMDHOSB8ZHI0-- From mary.ietf.barnes@gmail.com Wed Feb 13 12:27: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 304C221F870C for ; Wed, 13 Feb 2013 12:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 32-ceAgUEBM5 for ; Wed, 13 Feb 2013 12:27:23 -0800 (PST) Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 45D3521F870A for ; Wed, 13 Feb 2013 12:27:23 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id 6so734590qea.24 for ; Wed, 13 Feb 2013 12:27:22 -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:content-type; bh=xMgvfs0aID7f70cc1IXTsxAzD37NS76tVm2N4Sfq5Gc=; b=0eZKwLNPk+NKI/+tr2+6Tt2UJ/EZB3Cnsnz9B5gNcXL3Hq1o3n93Sb7I2iiODzGO6e 90EBPz73Y9TpzkiHOQVHBceIGMZhD2p3uk+T8y+79RwD+YV40M1Uw3zt/kWoVrK0nP1N cf7qFOg8ojAVkhEAzKLlOTOcZl9Vr7IPhKDXCKUA8wNmdggh793QpaaJELyfE7CH4Bmf YtgStqd3Ag2fHs1Ijg+fAKgN7oyh43T5dgx50tWsh+u+8Bph+CCaGzHQr51afA5lTvsO ipo6e/kzaW35HQDxJPcp7vFvhbvhQJOaWzhl1eWoQG+jX0wmY36XAIkYGGiF0Xd1b9aw cWDQ== MIME-Version: 1.0 X-Received: by 10.229.201.200 with SMTP id fb8mr2131206qcb.122.1360787241938; Wed, 13 Feb 2013 12:27:21 -0800 (PST) Received: by 10.49.131.199 with HTTP; Wed, 13 Feb 2013 12:27:21 -0800 (PST) In-Reply-To: <1731886884.8842607.1360787063654.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> References: <1731886884.8842607.1360787063654.POLL_ADMIN_PARTICIPATELINK.doodle@worker2> Date: Wed, 13 Feb 2013 14:27:21 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: Doodle: Link for poll "CLUE Design team meeting @ IETF-86" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 20:27:24 -0000 Hi all, As we discussed on Monday's call, I would like to arrange a design team meeting during the IETF week (between the two WG sessions). Looking at the agenda, I can only see a few slots where folks should be available: http://www.doodle.com/nqrdkdes42aaur8n Please fill out the doodle by Feb. 18th, 5 pm Pacific so I can request a room. Note, I will do a separate doodle for a dinner, but I don't anticipate we can get much work done there. Thanks, Mary. ---------- Forwarded message ---------- From: Doodle Date: Wed, Feb 13, 2013 at 2:24 PM Subject: Doodle: Link for poll "CLUE Design team meeting @ IETF-86" To: mary.ietf.barnes@gmail.com You have initiated a poll "CLUE Design team meeting @ IETF-86" at Doodle. The link to your poll is: http://www.doodle.com/nqrdkdes42aaur8n Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) From Mark.Duckworth@polycom.com Thu Feb 14 03:19: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 AB7DE21F8476 for ; Thu, 14 Feb 2013 03:19:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjRpF9KOk3aZ for ; Thu, 14 Feb 2013 03:19:50 -0800 (PST) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id CEE7021F8511 for ; Thu, 14 Feb 2013 03:19:47 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 14 Feb 2013 03:19:47 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 14 Feb 2013 03:19:44 -0800 Thread-Topic: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt Thread-Index: Ac4JhPk+aI0gBnlhTKuN8dEPKnPw7wBICz7g Message-ID: <9C23AB934B394845A7B228239B6EAF4104FD5A@CRPMBOXPRD01.polycom.com> References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 11:19:52 -0000 Yes. > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Mary Barnes > Sent: Tuesday, February 12, 2013 4:57 PM > To: CLUE > Cc: Jonathan Lennox > Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp- > mapping-05.txt >=20 > Hi all, >=20 > We would like to determine consensus for adopting this document as the > basis for a CLUE WG deliverable. As usual, accepting the document as a W= G > document does not mean that there is not a need for additional changes, i= t > just means this is a good starting point. >=20 > If folks could please respond "Yes" or "No" as to whether you agree with > adopting this document as a WG document no later than Thursday, Feb. > 14th, 2013 @ 5pm Pacific. >=20 > Thanks, > Mary. >=20 > On Fri, Feb 1, 2013 at 4:27 AM, Roni Even > wrote: > > > > ________________________________________ > > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > > Sent: Friday, February 01, 2013 12:24 PM > > To: Roni Even > > Cc: jonathan@vidyo.com > > Subject: New Version Notification for > > draft-even-clue-rtp-mapping-05.txt > > > > A new version of I-D, draft-even-clue-rtp-mapping-05.txt > > has been successfully submitted by Roni Even and posted to the IETF > > repository. > > > > Filename: draft-even-clue-rtp-mapping > > Revision: 05 > > Title: Mapping RTP streams to CLUE media captures > > Creation date: 2013-02-01 > > WG ID: Individual Submission > > Number of pages: 19 > > URL: http://www.ietf.org/internet-drafts/draft-even-clue-rt= p- > mapping-05.txt > > Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-ma= pping > > Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping= -05 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-clue-rtp= -mapping- > 05 > > > > Abstract: > > This document describes mechanisms and recommended practice for > > mapping RTP media streams defined in SDP to CLUE media captures. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > 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 coverdale@sympatico.ca Thu Feb 14 06:06: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 4230E21F87C4 for ; Thu, 14 Feb 2013 06:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] 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 YfJFd9FjCSnp for ; Thu, 14 Feb 2013 06:06:23 -0800 (PST) Received: from blu0-omc1-s24.blu0.hotmail.com (blu0-omc1-s24.blu0.hotmail.com [65.55.116.35]) by ietfa.amsl.com (Postfix) with ESMTP id 21BDC21F8488 for ; Thu, 14 Feb 2013 06:06:15 -0800 (PST) Received: from BLU0-SMTP37 ([65.55.116.7]) by blu0-omc1-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Feb 2013 06:06:14 -0800 X-EIP: [hPnjiKRzxzWGqzQ9/muUFyJghTxI0AOe] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([70.26.42.164]) by BLU0-SMTP37.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Feb 2013 06:06:12 -0800 From: Paul Coverdale To: "'Mary Barnes'" , "'CLUE'" References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> In-Reply-To: Date: Thu, 14 Feb 2013 09:06:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4JhPwWoi4Li48nSzmAVj3pmtk9hQBN1sVg Content-Language: en-us X-OriginalArrivalTime: 14 Feb 2013 14:06:13.0077 (UTC) FILETIME=[7275B850:01CE0ABC] Cc: 'Jonathan Lennox' Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 14:06:24 -0000 Yes. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Mary Barnes >Sent: Tuesday, February 12, 2013 7:57 PM >To: CLUE >Cc: Jonathan Lennox >Subject: Re: [clue] FW: New Version Notification for draft-even-clue- >rtp-mapping-05.txt > >Hi all, > >We would like to determine consensus for adopting this document as the >basis for a CLUE WG deliverable. As usual, accepting the document as a >WG document does not mean that there is not a need for additional >changes, it just means this is a good starting point. > >If folks could please respond "Yes" or "No" as to whether you agree with >adopting this document as a WG document no later than Thursday, Feb. >14th, 2013 @ 5pm Pacific. > >Thanks, >Mary. > >On Fri, Feb 1, 2013 at 4:27 AM, Roni Even >wrote: >> >> ________________________________________ >> From: internet-drafts@ietf.org [internet-drafts@ietf.org] >> Sent: Friday, February 01, 2013 12:24 PM >> To: Roni Even >> Cc: jonathan@vidyo.com >> Subject: New Version Notification for >> draft-even-clue-rtp-mapping-05.txt >> >> A new version of I-D, draft-even-clue-rtp-mapping-05.txt >> has been successfully submitted by Roni Even and posted to the IETF >> repository. >> >> Filename: draft-even-clue-rtp-mapping >> Revision: 05 >> Title: Mapping RTP streams to CLUE media captures >> Creation date: 2013-02-01 >> WG ID: Individual Submission >> Number of pages: 19 >> URL: http://www.ietf.org/internet-drafts/draft-even-clue- >rtp-mapping-05.txt >> Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp- >mapping >> Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp- >mapping-05 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp- >mapping-05 >> >> Abstract: >> This document describes mechanisms and recommended practice for >> mapping RTP media streams defined in SDP to CLUE media captures. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> 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 Feb 14 06:39: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 AB63921F8812 for ; Thu, 14 Feb 2013 06:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.088, 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 uL0ONKQHtBML for ; Thu, 14 Feb 2013 06:39:40 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE06421F8804 for ; Thu, 14 Feb 2013 06:39:39 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-07-511cf72a4b2f Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 35.F9.10459.A27FC115; Thu, 14 Feb 2013 15:39:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 15:39:38 +0100 From: Christer Holmberg To: Roni Even , "clue@ietf.org" Thread-Topic: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt Thread-Index: AQHOAGZFhqkzxGtQfkOnEc8pSy+fOphkzFhbgBS0y8A= Date: Thu, 14 Feb 2013 14:39:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D87C8@ESESSMB209.ericsson.se> References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> 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+Jvja7Wd5lAg761uhb7T11mtnjS8oPZ gcljyZKfTB47Nj9gDWCK4rJJSc3JLEst0rdL4Mrob7/NXtDAV/Ft13qWBsZN3F2MnBwSAiYS zQ/2MEHYYhIX7q1n62Lk4hASOMQosfDKKWYIZwmjxP15pxi7GDk42AQsJLr/aYOYIgI+Evf2 SYL0CgtESpyYcocdxBYRiJK4smo/I4RtBVTyBSzOIqAqceLLYzYQm1fAW+LO3SdMEOP7GCVe 3OoEO4JTIFzizcMzYA2MQAd9P7UGLM4sIC5x68l8qEMFJJbsOc8MYYtKvHz8jxXCVpTYebad GaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LL DTcxAmPh4JbfujsYT50TOcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj 6R3V3841mcpZh2PkVBZx3O/1mOTRddZhXVpMgeSsL5U7JOfH7PrAxFca8Hre95NsZ2yT/I7s OZ+SJRuWzfOul6fq8vmyq5PCn97XicrtnOF8YGuIcaRaKtvpq8YyCh7748yXbssva3jytNB7 /VYPvXQplbO/itlL7nuI8CpclNnTxsSZUKfEUpyRaKjFXFScCAADPJooUwIAAA== Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 14:39:40 -0000 Hi, One question. Does the "outcome" of the Boston interim affect this draft? For example, it does uses multiple SSRCs per m- line. Is the intention that= CLUE will push for that, eventhough RTCWEB might go in another direction? Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: 1. helmikuuta 2013 12:27 To: clue@ietf.org Subject: [clue] FW: New Version Notification for draft-even-clue-rtp-mappin= g-05.txt ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Friday, February 01, 2013 12:24 PM To: Roni Even Cc: jonathan@vidyo.com Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt A new version of I-D, draft-even-clue-rtp-mapping-05.txt has been successfully submitted by Roni Even and posted to the IETF reposit= ory. Filename: draft-even-clue-rtp-mapping Revision: 05 Title: Mapping RTP streams to CLUE media captures Creation date: 2013-02-01 WG ID: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-ma= pping-05.txt Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mappin= g Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-clue-rtp-map= ping-05 Abstract: This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. The IETF Secretariat _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From apeppere@gmail.com Thu Feb 14 09:22: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 29FB021F8939 for ; Thu, 14 Feb 2013 09:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219] 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 yKfZD-tnJnZa for ; Thu, 14 Feb 2013 09:22:15 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB621F885C for ; Thu, 14 Feb 2013 09:22:09 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so2569888lab.0 for ; Thu, 14 Feb 2013 09:22:08 -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=xQUJ59Pb/lHG8ZwUHsx5297Gl+Gm/ZUcGyLpyGKYgi0=; b=x17CKDC+XRLTnN+2z7HB5Eo9wNowyzJO4Ike9q32THZMg0n+RSG9/pnlFVOlgyAZwy LnCWirJ2/0z0X1IldeXVDlx+LQ1yFxs1UDqD8EYsQigYFmvFNULlHmMK9CZ9+x6MP6oc FAN2b1qI9EmOlqxNzHnhiZFuL43FzhniupfFewhZLjke3UvGsyQ4o/g0jnHT3ergGYws LBSHVlTNTU7rbZxyAmGvW9i9iSyzcJCFoHfv9xHNDQfCyLcCnhfpeN8PrCRHGDMbjJgP 4FoLSgwiq7RXfmJ+WCbYXconGWHStjTXTYNPHk7uUsEu6E5gdmxZwuA0k67qSARVunOD LH+Q== MIME-Version: 1.0 X-Received: by 10.152.105.17 with SMTP id gi17mr24384217lab.46.1360862528603; Thu, 14 Feb 2013 09:22:08 -0800 (PST) Received: by 10.112.32.101 with HTTP; Thu, 14 Feb 2013 09:22:07 -0800 (PST) In-Reply-To: References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> Date: Thu, 14 Feb 2013 17:22:07 +0000 Message-ID: From: Andy Pepperell To: Mary Barnes Content-Type: multipart/alternative; boundary=f46d040892fd9b05b604d5b27f56 Cc: CLUE Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 17:22:16 -0000 --f46d040892fd9b05b604d5b27f56 Content-Type: text/plain; charset=ISO-8859-1 Yes Andy --f46d040892fd9b05b604d5b27f56 Content-Type: text/html; charset=ISO-8859-1 Yes

Andy

--f46d040892fd9b05b604d5b27f56-- From pkyzivat@alum.mit.edu Thu Feb 14 10:25: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 BF54B21F85ED for ; Thu, 14 Feb 2013 10:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.288 X-Spam-Level: X-Spam-Status: No, score=-0.288 tagged_above=-999 required=5 tests=[AWL=0.149, 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 FVFAp4kIM9sy for ; Thu, 14 Feb 2013 10:25:25 -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 5BCF521F85E7 for ; Thu, 14 Feb 2013 10:25:25 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id 0HBm1l01b1ei1Bg53JRQxN; Thu, 14 Feb 2013 18:25:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id 0JRP1l00Q3ZTu2S3kJRQvc; Thu, 14 Feb 2013 18:25:24 +0000 Message-ID: <511D2C12.7020701@alum.mit.edu> Date: Thu, 14 Feb 2013 13:25:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> <7594FB04B1934943A5C02806D1A2204B0D87C8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0D87C8@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=1360866324; bh=GG0LmSU3lbIIG1A3xZR073zVOurZSwRym1/2qu+vL+o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=XImxSCYp4oEgu8TrlgjnjPyxXnmX9MdsCKL/f1z+c1+AOdKwwbgPV2JDh2wbteEtW HwITGatJjLuaJ+z/F9sdbA9qX+MrLWBO+aMONmyU5NZJkui5ozFo0PI0DTYG0+Sme8 OimpHwY6yVJ3n0Ez1gpQLjVCwLvnEn/IFa3/rj9mMvCnwcuuMuCNJ+anPjA6iqyb85 IVWWCuTdY/3sszepVqfbIJn9nkA8SqL6oIrsqi5eilEYxYlJVTpXjW4ffxcizLCoUY B1fbGef6lLSlkibuktIo/+14/TEuoRQECWZe1k8e1Z+dMdIpB0hHXzn7Ex1aJMeylr u24H3YTYfp5Jw== Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 18:25:27 -0000 On 2/14/13 9:39 AM, Christer Holmberg wrote: > Hi, > > One question. Does the "outcome" of the Boston interim affect this draft? > > For example, it does uses multiple SSRCs per m- line. Is the intention that CLUE will push for that, eventhough RTCWEB might go in another direction? IMO we don't know yet. Adopting this draft doesn't mean we have settled on that. Thanks, Paul > Regards, > > Christer > > > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: 1. helmikuuta 2013 12:27 > To: clue@ietf.org > Subject: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt > > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Friday, February 01, 2013 12:24 PM > To: Roni Even > Cc: jonathan@vidyo.com > Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt > > A new version of I-D, draft-even-clue-rtp-mapping-05.txt > has been successfully submitted by Roni Even and posted to the IETF repository. > > Filename: draft-even-clue-rtp-mapping > Revision: 05 > Title: Mapping RTP streams to CLUE media captures > Creation date: 2013-02-01 > WG ID: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-mapping-05.txt > Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapping > Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-05 > Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-rtp-mapping-05 > > Abstract: > This document describes mechanisms and recommended practice for > mapping RTP media streams defined in SDP to CLUE media captures. > > > > > The IETF Secretariat > _______________________________________________ > 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 Feb 14 10:30: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 8D27821F888E for ; Thu, 14 Feb 2013 10:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 vQLR1d+fstrb for ; Thu, 14 Feb 2013 10:30:48 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8801821F888A for ; Thu, 14 Feb 2013 10:30:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-fa-511d2d568c75 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 73.62.10459.65D2D115; Thu, 14 Feb 2013 19:30:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0318.004; Thu, 14 Feb 2013 19:30:45 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.txt Thread-Index: AQHOCuCwTv3X2wEA9E6Vpfj/k6VuXZh5rLZE Date: Thu, 14 Feb 2013 18:30:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D8959@ESESSMB209.ericsson.se> References: <20130201102406.16423.17070.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B7E22E@szxpml504-mbx.exmail.huawei.com> <7594FB04B1934943A5C02806D1A2204B0D87C8@ESESSMB209.ericsson.se>, <511D2C12.7020701@alum.mit.edu> In-Reply-To: <511D2C12.7020701@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+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW6YrmygwaN9Qhb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVx7c98poJfIhU35lo0MH4R6GLk5JAQMJF4 eXYrC4QtJnHh3nq2LkYuDiGBQ4wSbScboZwljBKTN69g7GLk4GATsJDo/qcN0iAi4Cmx4+MU ZhBbWCBS4nrTBXaIeJTEt4sTmCBsI4mN/ZNYQFpZBFQlfs8KBgnzCnhL3Po6hxli/AdGies7 loD1cgroSPT+fAA2kxHooO+n1oDNYRYQl7j1ZD4TxKECEkv2nGeGsEUlXj7+xwphK0rsPNvO DFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl hpsYgZFwcMtv3R2Mp86JHGKU5mBREucNc70QICSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoHR a77afrvAW2WPcs7cX+a8KDdqcmtRrwbfy0kmm8J0t/DHHe7OaLSeeVlTd//EhjNTumoqH1Xs XeDQPON98dlHTbfX32sO7zf8elv9z7X86Gcheskp9d9qDzNWXtjteWNy9sbJJQo7Tzz58q12 qcWKxvcVd27nnjtvF7pkZcEzN6tf/f5sB0OylFiKMxINtZiLihMB/aGLdVICAAA= Subject: Re: [clue] FW: New Version Notification for draft-even-clue-rtp-mapping-05.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 Feb 2013 18:30:49 -0000 So, yes from me too :) Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Thursday, 14 February 2013 8:25 PM To: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-even-= clue-rtp-mapping-05.txt On 2/14/13 9:39 AM, Christer Holmberg wrote: > Hi, > > One question. Does the "outcome" of the Boston interim affect this draft? > > For example, it does uses multiple SSRCs per m- line. Is the intention th= at CLUE will push for that, eventhough RTCWEB might go in another direction= ? IMO we don't know yet. Adopting this draft doesn't mean we have settled on that. Thanks, Paul > Regards, > > Christer > > > > > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of R= oni Even > Sent: 1. helmikuuta 2013 12:27 > To: clue@ietf.org > Subject: [clue] FW: New Version Notification for draft-even-clue-rtp-mapp= ing-05.txt > > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Friday, February 01, 2013 12:24 PM > To: Roni Even > Cc: jonathan@vidyo.com > Subject: New Version Notification for draft-even-clue-rtp-mapping-05.txt > > A new version of I-D, draft-even-clue-rtp-mapping-05.txt > has been successfully submitted by Roni Even and posted to the IETF repos= itory. > > Filename: draft-even-clue-rtp-mapping > Revision: 05 > Title: Mapping RTP streams to CLUE media captures > Creation date: 2013-02-01 > WG ID: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-even-clue-rtp-= mapping-05.txt > Status: http://datatracker.ietf.org/doc/draft-even-clue-rtp-mapp= ing > Htmlized: http://tools.ietf.org/html/draft-even-clue-rtp-mapping-0= 5 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-clue-rtp-m= apping-05 > > Abstract: > This document describes mechanisms and recommended practice for > mapping RTP media streams defined in SDP to CLUE media captures. > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Feb 15 10:46:46 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 83F3221F877B for ; Fri, 15 Feb 2013 10:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 iRL+bCx-SYcy for ; Fri, 15 Feb 2013 10:46:46 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5BCE21F865B for ; Fri, 15 Feb 2013 10:46:45 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id a11so1588076qen.17 for ; Fri, 15 Feb 2013 10:46:41 -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:content-type; bh=WU1xJls91SPi8z+WrIcH+O2hMxUDydPav5CtzqZs7E4=; b=QAM11x3LDxPTbU1VS+KOUA5YAy+pWdUiQEWigLhjnNrHMk3r6yvEjOTjus5eBGa9ww c2viWx3bRrEQreYXgnr/BXMVkWcQMsDeL0t7bVtj/pxjGoHOZyV6SemF4v6n+b+B2z4l dFk0mfc8duu/QH6ZDsKPxHv6ZLChA2LrcId4y/NZxhpNKEcUom7RsHCh1uFP1AMqHxmg +I/Z1wIxx0EPoZcLke4HGCgCP2y8xtfhbAlVII2qTkP0gyQ9Y3pwC45rpLfLN3S/mQb4 HBifiIbUFgJOpBEYXMROsFEA6T1z7QAYBFAXLe26CDF27IdUm0LsL+/oCMoeegeWnIZ+ 3PCg== MIME-Version: 1.0 X-Received: by 10.224.106.201 with SMTP id y9mr326240qao.3.1360954001456; Fri, 15 Feb 2013 10:46:41 -0800 (PST) Received: by 10.49.131.199 with HTTP; Fri, 15 Feb 2013 10:46:41 -0800 (PST) In-Reply-To: <20130215184321.8607.90539.idtracker@ietfa.amsl.com> References: <20130215184321.8607.90539.idtracker@ietfa.amsl.com> Date: Fri, 15 Feb 2013 12:46:41 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: Internet Draft Initial Version (-00) Cut-Off Monday, February 18 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 18:46:46 -0000 Just a reminder... ---------- Forwarded message ---------- From: Internet-Drafts Administrator Date: Fri, Feb 15, 2013 at 12:43 PM Subject: Internet Draft Initial Version (-00) Cut-Off Monday, February 18 To: IETF Announcement List Cc: ietf@ietf.org This is a reminder that the Internet Draft Initial Version (-00) cut- off is this coming Monday, February 18th, 2013. Please note that, because the AMS office is closed this Monday, manual submissions will not be processed until Tuesday, February 19th. All Initial Version (-00) submissions are due by UTC 24:00. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 86 can be found at: https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 Thank you for your understanding and cooperation. If you have any questions or concerns please send a message to internet-drafts@ietf.org. From mary.ietf.barnes@gmail.com Fri Feb 15 11:30: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 8A89E21F853A for ; Fri, 15 Feb 2013 11:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 OACxaDcXjynC for ; Fri, 15 Feb 2013 11:30:23 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id D669621F8441 for ; Fri, 15 Feb 2013 11:30:16 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id n41so1306542qco.7 for ; Fri, 15 Feb 2013 11:30:16 -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:content-type; bh=6c51OiWOwwMg1yn+pji47TG6HbhZyjEwCIuRjIVbZUQ=; b=oWr8N1zX7LsIjuycMqp4SWCRY7hGvo78HPWnrlNPcit4sZzjiBKrPUIV/fH4IeraPS /ToYuyIXhvCk6i1BdcaEe4pSwM1JK02/N0RvlA4csix90io27OVO/YN32Q/DHwhDhECk 8oeF68m0MPvQOsrete0ldjAfzE0SOl/+1iFxuMEUP2YxWgaaSJaJyn0vvySss/gMX+bD MkF/jlFlrKbtNVTUvll76Ru8Q2nF49T6sMZXpgcgnDr9VeLecZ8UxdNSZrGw1QuvIKAB HOjK/TWtXGsS1mmz+UhtIF3GbiKfuqGmbqx6u5IQyPEk/EHDWKLEhJA5SCZ5qHI4tms5 +prg== MIME-Version: 1.0 X-Received: by 10.229.137.75 with SMTP id v11mr135719qct.26.1360956616170; Fri, 15 Feb 2013 11:30:16 -0800 (PST) Received: by 10.49.131.199 with HTTP; Fri, 15 Feb 2013 11:30:16 -0800 (PST) In-Reply-To: References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.com> Date: Fri, 15 Feb 2013 13:30:16 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 19:30:24 -0000 Folks from CLUE WG should consider attending. I'm assuming at least Jonathan and Roni will be attend? I will only be able to attend about the first 30-45 minutes, so we definitely should have someone else there to report back. Mary ---------- Forwarded message ---------- From: Cullen Jennings (fluffy) Date: Fri, Feb 15, 2013 at 10:36 AM Subject: [MMUSIC] Call about Bundle Ports Feb 21 To: "mmusic@ietf.org (E-mail)" Hi All, As discussed at the interim, Richard and I are planning to have a call to discuss issues around the same port or different ports in bundle. This is not an official WG call or anything but anyone is welcome to join us on the call. Bridge info below. Cullen Cullen Jennings invites you to attend this online meeting. Topic: Bundle Ports Date: Thursday, February 21, 2013 Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 207 772 340 Meeting Password: ietf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&RT=MiM0 2. Enter your name and email address. 3. Enter the meeting password: ietf 4. Click "Join Now". To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&ORT=MiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiMwm3e2Gw&RT=MiM0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From pkyzivat@alum.mit.edu Fri Feb 15 11:44: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 6CCD521F868B for ; Fri, 15 Feb 2013 11:44:15 -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 AfR+AXayErQz for ; Fri, 15 Feb 2013 11:44:13 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 48E4A21F8632 for ; Fri, 15 Feb 2013 11:44:13 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 0hjF1l0081c6gX85BjkCuT; Fri, 15 Feb 2013 19:44:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:b464:eca0:470d:392]) by omta23.westchester.pa.mail.comcast.net with comcast id 0jjl1l00Z2UVY6i3jjjlY7; Fri, 15 Feb 2013 19:44:12 +0000 Message-ID: <511E8FF0.7090204@alum.mit.edu> Date: Fri, 15 Feb 2013 14:43:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.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=1360957452; bh=bKMJ4qk4GT7zDDQl0VatCKaPGWMbm1tp+Gir/EuenVU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=itYkXUU5Zl8Gw8LVITTIktfp29qfKnltCoAOQUZwUZSkBv+bTu/HtsE7y9rcvwgr+ AOpu+s6XazRahJs1PeRNSspsooIAljgPA7n92Ktrxi6Wh/gSk66fJN5RcWNsOohVU/ GtRMqc3HFP0fDA2d0kNgTkbwGnSUMa7UlzOIvN/mmM4GDjIspdRH+774uUxCWJ+dZ7 JYaE0KZCB7ywwB2/Wm1GYtv9OdZXu0oe1zccQUqsSZUMJHl6/K/hzVU8YTQdNIZDcC Ll5X9ahl06tNrqtGBWQa4Y0APL5I/D61vtU7k8+THne6RZf2hk7ofAAX5YLe+cWVcy l4KdDeJbhWJ+w== Subject: Re: [clue] Fwd: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 19:44:15 -0000 I saw it and put it on my calendar, but it is unlikely that I will be able to attend. I think I will be traveling at that time. Thanks, Paul On 2/15/13 2:30 PM, Mary Barnes wrote: > Folks from CLUE WG should consider attending. I'm assuming at least > Jonathan and Roni will be attend? I will only be able to attend about > the first 30-45 minutes, so we definitely should have someone else > there to report back. > > Mary > > > ---------- Forwarded message ---------- > From: Cullen Jennings (fluffy) > Date: Fri, Feb 15, 2013 at 10:36 AM > Subject: [MMUSIC] Call about Bundle Ports Feb 21 > To: "mmusic@ietf.org (E-mail)" > > > > Hi All, > > As discussed at the interim, Richard and I are planning to have a call > to discuss issues around the same port or different ports in bundle. > This is not an official WG call or anything but anyone is welcome to > join us on the call. Bridge info below. > > Cullen > > > > > Cullen Jennings invites you to attend this online meeting. > > Topic: Bundle Ports > Date: Thursday, February 21, 2013 > Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 207 772 340 > Meeting Password: ietf > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&RT=MiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: ietf > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2JjNzYz&ORT=MiM0 > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San > Jose/Milpitas area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiMwm3e2Gw&RT=MiM0 > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Fri Feb 15 12:15: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 0573321F8644 for ; Fri, 15 Feb 2013 12:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.587 X-Spam-Level: X-Spam-Status: No, score=-103.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Sw3YyQ6wkAI2 for ; Fri, 15 Feb 2013 12:15:55 -0800 (PST) Received: from mail-qe0-f49.google.com (mail-qe0-f49.google.com [209.85.128.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5630A21F863C for ; Fri, 15 Feb 2013 12:15:55 -0800 (PST) Received: by mail-qe0-f49.google.com with SMTP id 5so1607430qea.8 for ; Fri, 15 Feb 2013 12:15:54 -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=kTDD4Ezyoho3mlZ7yvL2QvivXajUWHQh4sysWns8gHA=; b=DSJ3bBpY34HJYVpYF84mYpwMwEwFF9hnsy4FcN16gOAi1gftU4RQf7m8wA6w8WXR7+ FtU7BiJ4551vKmz3cfF/JUclTB29NMR+rsRT8DrT+eAO1Hgn27Ni382n83EbI2zB7ara +ffRb9JHZ0Av3Gk6jSG+joyt6RbUDRkHOCBjtLdCLqPEKiDVFGPi9rKXnJZhUBdbEfLr OB4mUm5sFzH3X0H+gN68cV5ZHzN97ymTZQgcocKTNkGQ3E0QVcpQMunkVW1VxigstZIU TAWWHED57s06p5uzLOGkqLorwmE8EguxW3FLycMMsimZwhLqDr+VaBgvSuqItg0wBVj9 MUzA== MIME-Version: 1.0 X-Received: by 10.49.127.139 with SMTP id ng11mr1382245qeb.54.1360959354748; Fri, 15 Feb 2013 12:15:54 -0800 (PST) Received: by 10.49.131.199 with HTTP; Fri, 15 Feb 2013 12:15:54 -0800 (PST) Date: Fri, 15 Feb 2013 14:15:54 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] CLUE DT call on Monday Cancelled X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 20:15:56 -0000 Due to the unavailability of some folks, the fact that it's a US holiday and it's the -00 draft deadline, we will not have a design team call on Monday, Feb. 18th. Regards, Mary. From mary.ietf.barnes@gmail.com Fri Feb 15 13:42: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 5435321E8044 for ; Fri, 15 Feb 2013 13:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 hggp-+KTEvNq for ; Fri, 15 Feb 2013 13:42:48 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5BC21E8043 for ; Fri, 15 Feb 2013 13:42:48 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id a22so1377287qcs.12 for ; Fri, 15 Feb 2013 13:42:47 -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:content-type; bh=2RnhD9XDC4FSUf11xG4HYV7rlQEuaGQKBzHPEntLucw=; b=F+GiLmtJ1ILv0sKk/2BLQnHFA0G9aNqJK8pJlpVq0AOCdDvqAavyvc/jQhFYEiXAlz MpGaTN8iJmV7MaOWtZ8BnswihGTY4K0PF/kUAgB/BTg4nsgtHQHiuvarGK1zhe6lcUG5 Y7jS0K75QITkHEcXAlgBnLBr5dQhcHhX95FmrmLVZdzeCSyxdOLte99KbrCY5LrmQlf+ eawUpHpMABS89Qmd+3r2DhqIUmlOGFcghDjt0WBNoB1KKPqUUIv2WLP7+xyL7GJRyGGk a2xK45T2YVrYKZAE7Kf0IgRKQRAxkpIGnIk7RIDyO7BzSLsL9naOAk4khsot3UBIeIdG tuDA== MIME-Version: 1.0 X-Received: by 10.224.216.65 with SMTP id hh1mr2372616qab.43.1360964567579; Fri, 15 Feb 2013 13:42:47 -0800 (PST) Received: by 10.49.131.199 with HTTP; Fri, 15 Feb 2013 13:42:47 -0800 (PST) In-Reply-To: <1051713226.2950775.1360964358731.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> References: <1051713226.2950775.1360964358731.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Fri, 15 Feb 2013 15:42:47 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: Doodle: Link for poll "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: Fri, 15 Feb 2013 21:42:49 -0000 Hi all, As usual, we would like to organize a dinner for CLUE WG participants (unhosted). At this point, it looks like Monday or Wed are best for me. If folks could please respond no later than Friday, March 7th, so I can confirm a location that can support the group size. http://www.doodle.com/xaqdxztxrpt8h6wq Note that the time is based on the ending time for the plenaries which are way too long IMHO, but given the change in guard and the topic for the technical plenary, it's probably worthwhile to attend. Thanks, Mary. From christer.holmberg@ericsson.com Fri Feb 15 13:57: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 040B021F85BC for ; Fri, 15 Feb 2013 13:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.302 X-Spam-Level: X-Spam-Status: No, score=-6.302 tagged_above=-999 required=5 tests=[AWL=-0.053, 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 5vvJwvTRpO-r for ; Fri, 15 Feb 2013 13:57:53 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BAAEB21F85B8 for ; Fri, 15 Feb 2013 13:57:52 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-49-511eaf5f409d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 8B.3B.32353.F5FAE115; Fri, 15 Feb 2013 22:57:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.195]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 22:57:51 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Fwd: [MMUSIC] Call about Bundle Ports Feb 21 Thread-Index: AQHOC5qT7lCiNcVIEk6g/IzOibGGRJh7PcoAgAADxACAADYfgA== Date: Fri, 15 Feb 2013 21:57:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0D96B3@ESESSMB209.ericsson.se> References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.com> , <511E8FF0.7090204@alum.mit.edu> In-Reply-To: <511E8FF0.7090204@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+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvjW78erlAg1tzLSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujefsnloIz8hX3Hk9ma2BcL9XFyMkhIWAi cevdVSYIW0ziwr31bF2MXBxCAocYJSY+msMCkhASWMIosWapbxcjBwebgIVE9z9tkLCIgKfE jo9TmEFsYQEHiYZTO1lASkQEHCW+9eRDlDhJLFv2nw3EZhFQlVi/ZTfYKl4Bb4k3e14zQ6z6 zShx/tpTRpAEp4COxI/L38AaGIHu+X5qDVgDs4C4xK0n86HuFJBYsuc8M4QtKvHy8T9WCFtR 4uOrfYwQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6b mJmTXm6+iREYCQe3/DbYwbjpvtghRmkOFiVx3nDXCwFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGEu2LPDxFZjRXMkkxnNW3cuT/2ZtuKta68tYxSz5aWdacw+UKLNd66u9XhOX0HXA+Gx8 FHugzpfu77/Vu3cet5D6UMKlXV339er0thjGycIL4hm39Grbr4u3vPB3Z4wzx8njkslm+y6e 7dXd9zWdU1pcpbTBUVpEzCVP1K3A/kpZyfPUCUeVWIozEg21mIuKEwG5h/SqUgIAAA== Subject: Re: [clue] Fwd: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 21:57:54 -0000 Hi, I'm planning to call in. Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Friday, 15 February 2013 9:43 PM To: clue@ietf.org Subject: Re: [clue] Fwd: [MMUSIC] Call about Bundle Ports Feb 21 I saw it and put it on my calendar, but it is unlikely that I will be able to attend. I think I will be traveling at that time. Thanks, Paul On 2/15/13 2:30 PM, Mary Barnes wrote: > Folks from CLUE WG should consider attending. I'm assuming at least > Jonathan and Roni will be attend? I will only be able to attend about > the first 30-45 minutes, so we definitely should have someone else > there to report back. > > Mary > > > ---------- Forwarded message ---------- > From: Cullen Jennings (fluffy) > Date: Fri, Feb 15, 2013 at 10:36 AM > Subject: [MMUSIC] Call about Bundle Ports Feb 21 > To: "mmusic@ietf.org (E-mail)" > > > > Hi All, > > As discussed at the interim, Richard and I are planning to have a call > to discuss issues around the same port or different ports in bundle. > This is not an official WG call or anything but anyone is welcome to > join us on the call. Bridge info below. > > Cullen > > > > > Cullen Jennings invites you to attend this online meeting. > > Topic: Bundle Ports > Date: Thursday, February 21, 2013 > Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) > Meeting Number: 207 772 340 > Meeting Password: ietf > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID= =3D0&PW=3DNMjYwN2JjNzYz&RT=3DMiM0 > 2. Enter your name and email address. > 3. Enter the meeting password: ietf > 4. Click "Join Now". > > To view in other time zones or languages, please click the link: > https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&PW= =3DNMjYwN2JjNzYz&ORT=3DMiM0 > > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- > > The affected toll free numbers are: (866) 432-9903 for the San > Jose/Milpitas area and (866) 349-3520 for the RTP area. > > Please dial the local access number for your area from the list below: > - San Jose/Milpitas (408) area: 525-6800 > - RTP (919) area: 392-3330 > > ------------------------------------------------------- > To join the teleconference only > ------------------------------------------------------- > 1. Dial into Cisco WebEx (view all Global Access Numbers at > http://cisco.com/en/US/about/doing_business/conferencing/index.html > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111 Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394 China: +86.10.8515.5666 > > ------------------------------------------------------- > > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ciscosales.webex.com/ciscosales/j.php?ED=3D217553672&UID=3D0&ICS= =3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiM= wm3e2Gw&RT=3DMiM0 > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Feb 15 14:03: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 39D2821E803C for ; Fri, 15 Feb 2013 14:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.588 X-Spam-Level: X-Spam-Status: No, score=-103.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Y5PJ9aXQJ37p for ; Fri, 15 Feb 2013 14:03:57 -0800 (PST) Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8E21E8034 for ; Fri, 15 Feb 2013 14:03:57 -0800 (PST) Received: by mail-qa0-f50.google.com with SMTP id dx4so515324qab.16 for ; Fri, 15 Feb 2013 14:03:57 -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:content-type; bh=Ym6NeAZx5DD/B+pyh6ChtDzTAfyPTMbz5HPcffr8h7s=; b=GnUR2mTRQ+t0xcbqKNBto7XGAngMvlVJm+bFPIHAfa9u3v6rNZLtwXlvC898cyr4uO 2mvS5bP7N31SsnrtYmb3d4lb1JlxDX08pjqBppCUDhwQnXHpCAmwRLjV8N/5HELfjabq 7weNW1ckfvNOLYABhsbVnnfPPr4sl6iKKhmVyi0E13ordOI9prPx2tGh7rFiK7muoTVl BmDq2RZF/V6tTTiHaXlTyFmwGnO5z5dn2VyN6lNUWEvZZtTJ8dZ+V5gAs16LZD8JNolX m1uCTysjTAgeDm/5yNeHvKMY5z1JGF5BhAthzSl5UN1sE+BfMLVuSHaNkmx9UYK1Ze1N mbeg== MIME-Version: 1.0 X-Received: by 10.49.96.33 with SMTP id dp1mr1544720qeb.60.1360965836915; Fri, 15 Feb 2013 14:03:56 -0800 (PST) Received: by 10.49.131.199 with HTTP; Fri, 15 Feb 2013 14:03:56 -0800 (PST) In-Reply-To: References: <1051713226.2950775.1360964358731.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Fri, 15 Feb 2013 16:03:56 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] Doodle: Link for poll "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: Fri, 15 Feb 2013 22:03:58 -0000 Also, if folks can indicate in the comment section if they have a car and are willing to drive. It doesn't look like there's a myriad of restaurants right nearby. It seems the better ones are around a 15 min drive. Thanks, Mary. On Fri, Feb 15, 2013 at 3:42 PM, Mary Barnes wrote: > Hi all, > > As usual, we would like to organize a dinner for CLUE WG participants > (unhosted). At this point, it looks like Monday or Wed are best for > me. If folks could please respond no later than Friday, March 7th, so > I can confirm a location that can support the group size. > http://www.doodle.com/xaqdxztxrpt8h6wq > > Note that the time is based on the ending time for the plenaries which > are way too long IMHO, but given the change in guard and the topic for > the technical plenary, it's probably worthwhile to attend. > > Thanks, > Mary. From ron.even.tlv@gmail.com Sat Feb 16 00:52: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 2CB1F21F86AC for ; Sat, 16 Feb 2013 00:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=0.636, 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 yMSplFJVx45H for ; Sat, 16 Feb 2013 00:52:44 -0800 (PST) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id A836121F86A6 for ; Sat, 16 Feb 2013 00:52:43 -0800 (PST) Received: by mail-ee0-f53.google.com with SMTP id e53so2088941eek.26 for ; Sat, 16 Feb 2013 00:52:42 -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 :content-language:thread-index; bh=Go8S99uMzKw1muqGYhvBvRIRm5qX1ISPd1PyxS1WL/s=; b=y1jfkR9wz0vTlFfTH/AQsiGERQ8wDy+3EkSH2WkL6sa+TPldXxAzfXgK1gROEuPboH CeMY2E/K4kMn9WeGkNQkE7DF5LyCa4zQpwipoTQD7/OHIl5lKV5i8DMJ0LgromsTetBU Z4lLElSV0C0kSKIjtklk4yi5SrYyN9pDYJO37age+ra0abaK6CDifve9XWD5qUO8gx/9 fyEx/WGSSfMtbUXhpBgUvZz+pRGxb1QL/DabKmP9sIVfcdi88O1hUVUXeNlnMHWULkrJ Phao65Dp3uSCUIJlVZZRFr+tRICShZPoGIV0H+DAotEFlFVLkjWMZflSuIR9i1mruAOX ASGg== X-Received: by 10.14.202.71 with SMTP id c47mr18157210eeo.39.1361004762747; Sat, 16 Feb 2013 00:52:42 -0800 (PST) Received: from RoniE (bzq-79-181-179-229.red.bezeqint.net. [79.181.179.229]) by mx.google.com with ESMTPS id 46sm18184095eea.3.2013.02.16.00.52.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 16 Feb 2013 00:52:41 -0800 (PST) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: <2083996627.114593.1360940238764.JavaMail.nobody@jsj6tc002.webex.com> In-Reply-To: Date: Sat, 16 Feb 2013 10:49:33 +0200 Message-ID: <01ab01ce0c22$8c9e77a0$a5db66e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-language: en-us Thread-index: AQGeBegJN15eVzKnsr9NkvebvsTwFwDYaTdbAVv7u82YypVncA== Subject: Re: [clue] Fwd: [MMUSIC] Call about Bundle Ports Feb 21 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 16 Feb 2013 08:52:45 -0000 Hi Mary, I will not be able to attend, going on vacation between Feb 21 and march 1st. As for the topic, it is a question of which solution (using same port on all m-lines or different ports and indicate that they should be a single one) will cause less problem to existing products. So people who have input should attend the call. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 15 February, 2013 9:30 PM To: CLUE Subject: [clue] Fwd: [MMUSIC] Call about Bundle Ports Feb 21 Folks from CLUE WG should consider attending. I'm assuming at least Jonathan and Roni will be attend? I will only be able to attend about the first 30-45 minutes, so we definitely should have someone else there to report back. Mary ---------- Forwarded message ---------- From: Cullen Jennings (fluffy) Date: Fri, Feb 15, 2013 at 10:36 AM Subject: [MMUSIC] Call about Bundle Ports Feb 21 To: "mmusic@ietf.org (E-mail)" Hi All, As discussed at the interim, Richard and I are planning to have a call to discuss issues around the same port or different ports in bundle. This is not an official WG call or anything but anyone is welcome to join us on the call. Bridge info below. Cullen Cullen Jennings invites you to attend this online meeting. Topic: Bundle Ports Date: Thursday, February 21, 2013 Time: 7:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 207 772 340 Meeting Password: ietf ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2J jNzYz&RT=MiM0 2. Enter your name and email address. 3. Enter the meeting password: ietf 4. Click "Join Now". To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&PW=NMjYwN2J jNzYz&ORT=MiM0 ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ciscosales.webex.com/ciscosales/j.php?ED=217553672&UID=0&ICS=MI&LD=1 &RD=2&ST=1&SHA2=AAAAAkvkBwPvL1IZY/a2pGU6xcxB7i5WW2-fXSdiMwm3e2Gw&RT=MiM0 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From internet-drafts@ietf.org Sun Feb 17 10:19: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 F2C2D21F8B07; Sun, 17 Feb 2013 10:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hb0aC81xXuh7; Sun, 17 Feb 2013 10:19:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5469921F84E2; Sun, 17 Feb 2013 10:19:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130217181935.30724.5333.idtracker@ietfa.amsl.com> Date: Sun, 17 Feb 2013 10:19:35 -0800 Cc: clue@ietf.org Subject: [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: Sun, 17 Feb 2013 18:19:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : 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/ From mary.ietf.barnes@gmail.com Sun Feb 17 10:45: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 41A5F21F8B2E for ; Sun, 17 Feb 2013 10:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.988 X-Spam-Level: X-Spam-Status: No, score=-102.988 tagged_above=-999 required=5 tests=[AWL=-0.589, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 ouSzEqEzA+4J for ; Sun, 17 Feb 2013 10:45:25 -0800 (PST) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB8221F8B2B for ; Sun, 17 Feb 2013 10:45:25 -0800 (PST) Received: by mail-qe0-f50.google.com with SMTP id 7so2110925qea.23 for ; Sun, 17 Feb 2013 10:45:24 -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:content-type:content-transfer-encoding; bh=RDjLZxWaTcJiWZmwHDnAtQThkFH14nx1OLW5pdV8TCk=; b=Q26eFbppoHjCVLQm3rmjkQtaZE1roMXQ42Ls2fAzs/XIRgeACstKlIxet/O4X6XEz1 L5Nb/jrg0wrEmHblQxj7OSrV4TZyGgW3DxbWKdcsMreF5FtScydv+6/DFK2M2FJqDn4G WUkqkt5IJFv/STEDh0VzDwM7gKAlQfxA6S5u/ptm1dX681yBE/rlD/VBCVi4JuUExIbC pauiMg2Ks4QRxyPcyhZCCR19bExzVWa7P1qv444h95j40k2lR6hzrgqAllFlrI0lX9IA BiDIlPfK687S6/SEMwbv+7Tei3OF+qyirhj/lgEaMlWMJlntMbgkVePbElKqsnxGiG0P b5dQ== MIME-Version: 1.0 X-Received: by 10.224.27.136 with SMTP id i8mr3645269qac.63.1361126724892; Sun, 17 Feb 2013 10:45:24 -0800 (PST) Received: by 10.49.131.199 with HTTP; Sun, 17 Feb 2013 10:45:24 -0800 (PST) In-Reply-To: References: <5111247B.8060904@nostrum.com> <511CEDFF.7060001@ericsson.com> Date: Sun, 17 Feb 2013 12:45:24 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [clue] Fwd: [MMUSIC] More thoughts on multiple media streams in a single m= line X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Feb 2013 18:45:26 -0000 =10Another relevant discussion for CLUE. ---------- Forwarded message ---------- From: Bernard Aboba Date: Sat, Feb 16, 2013 at 2:53 PM Subject: Re: [MMUSIC] More thoughts on multiple media streams in a single m=3D line To: Magnus Westerlund Cc: "mmusic@ietf.org" Comments below. > I definitely want to comment on this from an RTP usage perspective that > might be very relevant to remember. Even with a centralized conference > solution there is two very distinct solutions in RTP how to transmit a > session where you have total of 100 participants and you receive 5 video > streams. > > A) Central point with conceptual sources > In this case the central entity creates conceptual RTP streams that > carries all the media intended for a specific usage, for example main > video, thumbnail one, thumbnail two, thumbnail three, thumbnail four. > > B) Central point doing source projection > In this case there exist 100 potential RTP streams and SSRC from the > central point down to the receiver. However, at any point no more than > five will actually have RTP packets. But as activity changes and which > is most relevant for the receiver the SSRCs in use will switch. > > For a solution where each SSRC requires its own m=3D line A) is definitel= y > preferable as it will not require renegotiating the properties for these > five conceptual streams. However, B will require a large number of m=3D > lines and dynamic updates as participants comes and go. [BA] I think there are advantages to A even if multiple SSRCs are declared within a m-line. If the "main" video and "thumbnails" change SSRCs, even with multiple SSRCs on an m-line, you'd still need to renegotiate unless SVC is being used, right? > If one had a single m=3D line per RTP session and media type, the amount > of updates/renegotiation depends on the amount of meta data about > streams that you have put in the SDP. The solutions A) and B) can be > identical from an SDP perspective. [BA] That's not obvious to me. Even if you have a single m=3Dline per RTP session and media type, you can still have individual a=3Dssrc lines within a m=3D line. In case B, as participants come and go, aren't dynamic updates still required? Also, instead of many m=3Dlines, you'll have many a=3Dssrc lines. > The above two cases I am quite certain we did discuss in the CLUE > interim meeting in Stockholm when discussing topologies and also the > relationship between RTP streams (SSRC) and their origin, i.e. media > source/capture. [BA] Were there any specific requirements that arose in the CLUE discussion? In general, given some of the context issues, it would be helpful to understand whether we're engineering a solution for RTCWEB use cases, CLUE use cases, or both. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From mary.ietf.barnes@gmail.com Sun Feb 17 10:55: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 C57E621F8B33 for ; Sun, 17 Feb 2013 10:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 IuvObWaSltWw for ; Sun, 17 Feb 2013 10:55:59 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 447A421F8B30 for ; Sun, 17 Feb 2013 10:55:59 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id bs12so982398qab.4 for ; Sun, 17 Feb 2013 10:55:58 -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=gueqWtLaWEtDzmfMRhXXHem154pkx2tnTt3y4n0fwc8=; b=CT/OBJRBG3dDUf0y2YoRz8Ms3EleCTN5moDhYNLteWVWj3SKO7NjaraC4K9KJ3CbIf 3pQdxl+wtOgki9yMp71WOrQ1JqaUDyTHsUQdyMTfa14+tktdZbNgYJi+rO8aryGGLpMa /A+WmipCN5nDPFR2rBU/RK0xmov1tt1kBGZKdFuSEkO+fQ7mNMacH/MGhNPJ97ijTN40 OaFYKPyjjc/CZo/4Zj0iTThdJfNWj0/RXL54mPpzMCwLtw0t/uJa4dN95x7TUC+Prh2h SG7Yk9Oo2A5kmJaJk6jjB7MpQYFLVK+w9w+7s9x7R/SWOhVzWx+0LN5NiQUT8b3tVvOh 3PJg== MIME-Version: 1.0 X-Received: by 10.49.96.33 with SMTP id dp1mr3919001qeb.60.1361127358658; Sun, 17 Feb 2013 10:55:58 -0800 (PST) Received: by 10.49.131.199 with HTTP; Sun, 17 Feb 2013 10:55:58 -0800 (PST) In-Reply-To: <511A7BE9.4080306@alum.mit.edu> References: <511A7BE9.4080306@alum.mit.edu> Date: Sun, 17 Feb 2013 12:55:58 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE Subject: Re: [clue] 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: Sun, 17 Feb 2013 18:55:59 -0000 Paul, I might have missed it, but I haven't seen the submission. Are you working offline with the other contributors or are they still waiting for the document? IMHO, the model should be that folks have their text ready to cut and paste and then they can do a review of what's there and fix any inconsistencies and add additional editorial notes/comments that come to mind. I don't think we'll make good progress if the document isn't turned around fairly quickly OR if you all can work together and produce a single update. Thanks, Mary. On Tue, Feb 12, 2013 at 11:29 AM, Paul Kyzivat wrote: > I'm working on an -02 version now, to be published in the next day or two. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Sun Feb 17 21:53: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 3FA4021F8AB2 for ; Sun, 17 Feb 2013 21:53:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w1WfJX6u6L9 for ; Sun, 17 Feb 2013 21:53:23 -0800 (PST) Received: from ipmail06.adl2.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 254F721F8716 for ; Sun, 17 Feb 2013 21:53:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAHjAIVF20X9s/2dsb2JhbAANN4N0glW5V4EagxIBAQEEIxUbFQ8BDQQbAQMBAgMCBRYLAgIJAwIBAgE7AggGDQYCAQEFiBAFrBtxkUaBI44JEgaCJ4ETA5dJklY Received: from ppp118-209-127-108.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.127.108]) by ipmail06.adl2.internode.on.net with ESMTP; 18 Feb 2013 16:23:18 +1030 Message-ID: <5121C1C9.7090902@nteczone.com> Date: Mon, 18 Feb 2013 16:53:13 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "clue@ietf.org" References: <20130218054933.26462.62794.idtracker@ietfa.amsl.com> In-Reply-To: <20130218054933.26462.62794.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130218054933.26462.62794.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Fwd: New Version Notification for draft-groves-clue-capture-attr-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 05:53:25 -0000 Hello all, I've just posted a v1 of the Capture attribute draft (http://www.ietf.org/internet-drafts/draft-groves-clue-capture-attr-01.txt). I based the updates based on the comments received to my emails posts regarding. This is summarised below: Summary of CLUE attribute progress ---------------------------------- 4.1 Presentation : No comments or concerns. 4.2 View : No comments or concerns. 4.3 Language: There were comments that multiple languages need to be supported e.g. audio in one, embedded text in another. The text need to be clear whether it is supported or preferred language however it was clarified it is neither. Its the language of the content/capture. It was also noted that different speakers using different languages could talk on the main speakers capture therefore language should be a list. Seemed to be support for this. 4.4 Role There were a couple of responses for support for this attribute. The actual values still need some work. It was noted that there were two possible sets of roles: One group related to the titles of the person: i.e. Boss, Chairman, Secretary, Lecturer, Audience Another group related to conference functions: i.e. Conference initiator, controller, speaker. 4.5 Priority No direct comment on the proposal. There appeared to be some interest in a prioritisation scheme during discussions on the framework 4.6.1 Dynamic : No comments or concerns. 4.6.2 Embedded text: There was a comment that "text" media capture was needed. It was also indicated that it should be possible to associate a language with embedded text. It should be possible to also specify language and script. e.g. Embedded text could have its own language. E.g. VC1 (Language=ase,EmbeddedText=en) This would indicate that the video contains American Sign Language and embedded text in English. With respect to language and scripts it appears that RFC5646 allows the use of language plus script sub-tag. i.e. zh-Hans (Chinese written using the Simplified Chinese script) 4.6.3 Supplementary Description There was a comments that it could be interpreted as a free text field. The intention is that its more of a flag. A better name could be "Complementary feed"? There was also a comment that perhaps a specific "translator flag" is needed. It was noted the usage was like: AC1 Language=English AC2 Supplementary Description = TRUE, Language=Chinese 4.6.4 Telepresence There were a couple of comments questioning the need for this parameter. This can be removed. It would be good to continue discussions on the list or at the upcoming meeting. Regards, Christian -------- Original Message -------- Subject: New Version Notification for draft-groves-clue-capture-attr-01.txt Date: Sun, 17 Feb 2013 21:49:33 -0800 From: internet-drafts@ietf.org To: christian.groves@nteczone.com CC: roni.even@mail01.huawei.com, tommy@huawei.com A new version of I-D, draft-groves-clue-capture-attr-01.txt has been successfully submitted by Christian Groves and posted to the IETF repository. Filename: draft-groves-clue-capture-attr Revision: 01 Title: CLUE media capture description Creation date: 2013-02-18 Group: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-groves-clue-capture-attr-01.txt Status: http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr Htmlized: http://tools.ietf.org/html/draft-groves-clue-capture-attr-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-groves-clue-capture-attr-01 Abstract: This memo discusses how media captures are described and in particular the content attribute in the current CLUE framework document and proposes several alternatives. The IETF Secretariat From pkyzivat@alum.mit.edu Mon Feb 18 06:15: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 8F59A21F899F for ; Mon, 18 Feb 2013 06:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.33 X-Spam-Level: X-Spam-Status: No, score=-0.33 tagged_above=-999 required=5 tests=[AWL=0.107, 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 WwYuO2Or6wHT for ; Mon, 18 Feb 2013 06:15:46 -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 F410621F89D5 for ; Mon, 18 Feb 2013 06:15:45 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id 1psn1l0031c6gX85DqFl1x; Mon, 18 Feb 2013 14:15:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 1qFk1l0123ZTu2S3jqFkek; Mon, 18 Feb 2013 14:15:45 +0000 Message-ID: <51223790.7060008@alum.mit.edu> Date: Mon, 18 Feb 2013 09:15:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mary Barnes References: <511A7BE9.4080306@alum.mit.edu> 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=1361196945; bh=phu0Xq3A0psxsFRmoGwTZcn69FJdBwsTQgxKroBEZBM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cZhfqnmhCrCc/hRumIYJH7Dbg66aSB5meTMi6wHFfC22KDzDX2BDMSS+ndXW7hnVn +J72mLiQwdn9ul2K1YlM4KLCO+cyOPL0gJ+gGp6s2BM+oDKTzYmwn6eptMZx0rTuMi C/W6QKxp/ljxAH61xr+LBvh6gLLeRs6TYxaUYxGEI/9S+R0R3ne05uURiPNceuSSfY x6iBeewzZeyergLZcc0OJCV9ql9DiREQ+9tzcX0YTIGZoWRwQ5L2CLiczyS3rnLJuU HteYgimpik5/Hj09exh0Uv9EbSi43kO4vQ5KqLiGBRMH42tdPOPhfurrW1COHdrvvP PlaFLsWULteAg== Cc: CLUE Subject: Re: [clue] 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, 18 Feb 2013 14:15:47 -0000 Yes, working offline. I should have it posted today. Thanks, Paul On 2/17/13 1:55 PM, Mary Barnes wrote: > Paul, > > I might have missed it, but I haven't seen the submission. Are you > working offline with the other contributors or are they still waiting > for the document? IMHO, the model should be that folks have their > text ready to cut and paste and then they can do a review of what's > there and fix any inconsistencies and add additional editorial > notes/comments that come to mind. I don't think we'll make good > progress if the document isn't turned around fairly quickly OR if you > all can work together and produce a single update. > > Thanks, > Mary. > > On Tue, Feb 12, 2013 at 11:29 AM, Paul Kyzivat wrote: >> I'm working on an -02 version now, to be published in the next day or two. >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Mon Feb 18 11:52: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 856F921F8A56 for ; Mon, 18 Feb 2013 11:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 Nbf+djoSMt7M for ; Mon, 18 Feb 2013 11:52:41 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D9C4321F8BD1 for ; Mon, 18 Feb 2013 11:52:40 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-cf-512286879267 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 26.49.32353.78682215; Mon, 18 Feb 2013 20:52:40 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 20:52:39 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 Thread-Index: Ac4OENvQrjUr6KWHTMaYkeb/AHwyXgAAJvMY Date: Mon, 18 Feb 2013 19:52:38 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0F5588@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B0F555F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0F555F@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW5Hm1KgwYo7zBb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtzbLawFU3kq+qY1MjcwtnF1MXJySAiYSJx5v5wVwhaTuHBv PVsXIxeHkMAhRomJM1exQziLGSUW3HwLVMXBwSZgIdH9TxukQURAWeLo5n42EFtYIEzi9+Zf bBDxcIlNV3vZIWwjibmfrjOB2CwCqhKNf86D2bwC3hIbvh9mBLGFgOzrR1YzgoznFPCROLgp FyTMCHTP91NrwMqZBcQlbj2ZzwRxp4DEkj3nmSFsUYmXj/9B3a8osfNsOzNEvY7Egt2f2CBs bYllC18zQ6wVlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxsucmZuakl5tvYgQG/cEtvw12 MG66L3aIUZqDRUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxkgXkQ2XP3BHCn/c YXg6TePqoz+PF6wzmb2w0kZYR0fMrKsl1exzl/rRd2dCuxfPt2QQ7sleq3fra/u2NKvYx/Ya +Yv/mxzQvudUxzY/qfhGm6/aF69p6k/SN6aw2YjOO7zB4e1mr8CN8UrHX/8+VLL6Wex/+4U6 MRMeWszJCHdccPHo1SzvuUosxRmJhlrMRcWJAFf9VRxIAgAA Subject: [clue] FW: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negotiation-03 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:52:41 -0000 FYI, Christer ________________________________________ From: mmusic-bounces@ietf.org [mmusic-bounces@ietf.org] on behalf of Christ= er Holmberg [christer.holmberg@ericsson.com] Sent: Monday, 18 February 2013 9:50 PM To: mmusic@ietf.org Subject: [MMUSIC] Draft new version: draft-ietf-mmusic-sdp-bundle-negoti= ation-03 Hi, I've submitted a new version (-03) of BUNDLE. Based on discussions with Cullen, and exchange of the concerns we had with = the different port alternatives (different-ports vs identical-port), this v= ersion now describes a mechanism where both alternatives more or less are c= ombined. When the first BUNDLE offer is sent, and it is now known whether t= he answerer supports BUNDLE (or, even identical ports), different ports are= used (read: the one-rtp alterntaive). Once BUNDLE answer has been received= , a new offer, with identical port numbers, is sent. We think that having to send a second offer is not going to increase comple= xity and delay, because in many use-cases subsequent offer(s) will be sent = anyway. For example, RTCWEB entities will do it because of ICE. Cullen has also been added as co-author. Now, we do realize that there are still issues that have to be described, a= nd hopefully we will be able to focus on those from now on, but our wish is= that this proposal will unite the different "port camps" :) Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From rohanse2@cisco.com Mon Feb 18 12:03: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 CCD4421F87F6 for ; Mon, 18 Feb 2013 12:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYGneR10Mawh for ; Mon, 18 Feb 2013 12:03:28 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2689221F87B6 for ; Mon, 18 Feb 2013 12:03:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=799; q=dns/txt; s=iport; t=1361217808; x=1362427408; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=oZ0HjYkkKesrcesPwLu9uINHeSRNu7V/TuIF+5N/kgE=; b=MWnK3PkKjCzjdLTViwpCbuWjvpEINJOfZe2AIefzA5bKRQ7nqP7jzVy0 C7U3HBJ/AKgwf+AyNEOo+G4Wx3Vr9PeZr8Uq39Mz/DH8pBGrh5ClOsF4V dI6TqLd3K9NPbPwvSwq60HwHJ4BvpJOCO1fcX+DOBmWz6hW5EUPCkGjf+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJyIIlGQ/khM/2dsb2JhbABEwSYWc4JeQD0WGAMCAQIBWAgBAYgOoBqhAI9UgyoDliyFcYpngwc X-IronPort-AV: E=Sophos;i="4.84,690,1355097600"; d="scan'208";a="80531263" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 18 Feb 2013 20:03:08 +0000 Received: from [10.47.196.105] ([10.47.196.105]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1IK37s9021268 for ; Mon, 18 Feb 2013 20:03:08 GMT Message-ID: <5122892C.6000804@cisco.com> Date: Mon, 18 Feb 2013 20:03:56 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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: Mon, 18 Feb 2013 20:03:29 -0000 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 From pkyzivat@alum.mit.edu Mon Feb 18 13:16: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 88EAA21F8CE2 for ; Mon, 18 Feb 2013 13:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.34 X-Spam-Level: X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[AWL=0.097, 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 LfPVny1gIa9h for ; Mon, 18 Feb 2013 13:16:08 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id B299F21F8CE1 for ; Mon, 18 Feb 2013 13:16:07 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta06.westchester.pa.mail.comcast.net with comcast id 1x1U1l0011c6gX856xG7lL; Mon, 18 Feb 2013 21:16:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 1xG61l00h3ZTu2S3jxG6XK; Mon, 18 Feb 2013 21:16:07 +0000 Message-ID: <51229A16.1040703@alum.mit.edu> Date: Mon, 18 Feb 2013 16:16:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: CLUE References: <20130218210147.7331.87836.idtracker@ietfa.amsl.com> In-Reply-To: <20130218210147.7331.87836.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130218210147.7331.87836.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=1361222167; bh=qXYtm4okEukJGUrbkfyNz5BX3M4XWNojshsXimtTkBI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BscI/EpNtmVkzblusq9XUN51diB3MLYF1jUNy2Se+kEX0WIj1C0Su6z6YbQhupV9g Q+G0nkA6T12G++rgca62ULf/jvH3r+j6vKi/VAXRHwmIGVvLuvPP3RTtfwQYP4Yeu7 PUJdp9XDcGRs5YlikTO5TnARZgNpmDnVps50rq+4PaPC1dBqYYggXRXt2Ai/5mxQZ1 t6rZTOZ9djV+iEZdGjKh0XTJ5cvnoURjx/0HGZXvI2y0JtYiweDtAu8I0huHKBBb7s 1Z8dmF7UKO9kB8EzQ8RR2myMODze25mFHI5glelFMeWsRhKaI81pL/tpYWNCVMiUwv 7vo7hRNWzLxcw== Subject: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-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 Feb 2013 21:16:08 -0000 I just posted the -02 version. There is now a history section that summarized the changes. Basically this includes a bunch of proposals by me and co-workers. Please consider these straw-horses. Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-clue-signaling-02.txt Date: Mon, 18 Feb 2013 13:01:47 -0800 From: internet-drafts@ietf.org To: pkyzivat@alum.mit.edu CC: lennard.xiao@huawei.com, christian.groves@nteczone.com A new version of I-D, draft-kyzivat-clue-signaling-02.txt has been successfully submitted by Paul Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-clue-signaling Revision: 02 Title: CLUE Signaling Creation date: 2013-02-18 Group: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-02.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-02 Abstract: This document specifies how signaling is conducted in the course of CLUE sessions. This includes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol that complements SIP/SDP and supports negotiation of CLUE application level data. The IETF Secretariat From pkyzivat@alum.mit.edu Mon Feb 18 13:43: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 05B1021F8C58 for ; Mon, 18 Feb 2013 13:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.344 X-Spam-Level: X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=0.093, 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 v9L0iqrSEwdv for ; Mon, 18 Feb 2013 13:43:15 -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 41B1421F8C5C for ; Mon, 18 Feb 2013 13:43:15 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id 1vKW1l0040Fqzac5FxjD3v; Mon, 18 Feb 2013 21:43:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id 1xjD1l00W3ZTu2S3UxjDq2; Mon, 18 Feb 2013 21:43:13 +0000 Message-ID: <5122A070.7010004@alum.mit.edu> Date: Mon, 18 Feb 2013 16:43:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <20130218210147.7331.87836.idtracker@ietfa.amsl.com> <51229A16.1040703@alum.mit.edu> In-Reply-To: <51229A16.1040703@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=1361223793; bh=nfdwvPcFrDiIwrgi5z5yikF3wiX7tJqbK5L0bG3uPZc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=lha+nps7fzm/rg6DXPybgRw/qZ/isF0GzfAc1rJ/TuuYQaN3lL5ccnsnFL14nfE8I zUwfqrxJl+s8RR6Fs+VABWVhApRqN144Pfezy+jjcNNrlHsOnyoIyI1nKfPvghqU9R IUj6Nz+UCPMsuoyXoOy8QlbD+d9I0xESmjzsogxIaaZt7P6RCQq9sdFcxxk5hq7cpQ mWPXFN413F1Il1L9fKZK996ddJ8OfTDjPfGz2Cmigq94jEmz+LfJUSkawNii8UAIX3 v7o9SDL03KDPsblgQDVQnaRTnxJox/l8/KAuyAgaSiQsjonFa6jgESvOrTOilZ1JZk aWhmVnVn+HZEg== Subject: Re: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-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 Feb 2013 21:43:16 -0000 IMO there is now sufficient "meat" here to have some serious discussion among the intended authors about which way we want to go on many things. So please start shooting. Thanks, Paul On 2/18/13 4:16 PM, Paul Kyzivat wrote: > I just posted the -02 version. > There is now a history section that summarized the changes. > Basically this includes a bunch of proposals by me and co-workers. > Please consider these straw-horses. > > Thanks, > Paul > > > -------- Original Message -------- > Subject: New Version Notification for draft-kyzivat-clue-signaling-02.txt > Date: Mon, 18 Feb 2013 13:01:47 -0800 > From: internet-drafts@ietf.org > To: pkyzivat@alum.mit.edu > CC: lennard.xiao@huawei.com, christian.groves@nteczone.com > > > A new version of I-D, draft-kyzivat-clue-signaling-02.txt > has been successfully submitted by Paul Kyzivat and posted to the > IETF repository. > > Filename: draft-kyzivat-clue-signaling > Revision: 02 > Title: CLUE Signaling > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 21 > URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-02.txt > Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling > Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-kyzivat-clue-signaling-02 > > Abstract: > This document specifies how signaling is conducted in the course of > CLUE sessions. This includes how SIP/SDP signaling is applied to > CLUE sessions as well as defining a CLUE-specific signaling protocol > that complements SIP/SDP and supports negotiation of CLUE application > level data. > > > > > > The IETF Secretariat > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Feb 18 14:11: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 3AA5A21F8D04 for ; Mon, 18 Feb 2013 14:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.346 X-Spam-Level: X-Spam-Status: No, score=-0.346 tagged_above=-999 required=5 tests=[AWL=0.091, 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 RnqbNG2CwyRM for ; Mon, 18 Feb 2013 14:11:21 -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 49B6721F8D03 for ; Mon, 18 Feb 2013 14:11:21 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id 1qC61l0031uE5Es55yBLRe; Mon, 18 Feb 2013 22:11:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id 1yBL1l00d3ZTu2S3cyBLMF; Mon, 18 Feb 2013 22:11:20 +0000 Message-ID: <5122A707.9070103@alum.mit.edu> Date: Mon, 18 Feb 2013 17:11:19 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <5122892C.6000804@cisco.com> In-Reply-To: <5122892C.6000804@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361225480; bh=I7OuBOq/592rX6JnbaBeP7fF8eVilOxq1OkNQSo62o0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=kFsgb8z+LkGm5JOmU9bvk926JIVdjyFtBQNWTw/l83clkwblBf0+X9DxldiRlyzlI MJ7pND4gl3pcpxrp2zTpuGkzGjvxAI4ifCQ9NZfNrrIJX+D7Ex7pIgyl9kav8nTVDa hEY/N2aY45M7OBVAdCvasU235hQwooH/M3BDkN20edlfmVe1pNZ+2yc+mNEzKmeU3A fIGrDz0CF3vVfNFz6TqUWXn1REkCTJswcpUiIf4Z5sRHv4IxDQl12E+EV6DkIQA0a3 B84tGPk99JRC8bhiEsKr/L9qyIdTCglZdxEgOpJp5JZytzrwxoqbvxMUhsJSOkfDwN KpAPfmtXMVKMQ== 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: Mon, 18 Feb 2013 22:11:26 -0000 Hi Rob, You make good points in this document. IMO this material fits well in section 4 of the signaling draft. The xml for the -02 version is posted, so please feel free to put this material in there. With regard to how much to put in SDP, I remain conflicted. There are advantages to putting all the encoding stuff in SDP, but starting to describe what can be sent as well as what can be received in O/A may open a can of worms. Certainly that needs to be discussed in the larger MMUSIC context, and may be difficult. Also, other applications that want to make use of that machinery will have to invent their own way to discover enough about the available encodings to decide which to choose. An alternative would be to conclude that much of CLUE is independent of telepresence - is rather just about negotiating which of a bunch of available captures to send and receive, while many of the specific attributes (e.g. spatial information) are telepresence specific. Then others could use the same machinery, but with different attributes specific to their application. In this approach, all the stuff about *available* encodings could be viewed as appropriate to the CLUE protocol, while the in-use encodings would continue to be part of SDP. I could go either way on this. Would like to hear what others have to say. Thanks, Paul (as individual) On 2/18/13 3:03 PM, 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 > From mary.ietf.barnes@gmail.com Tue Feb 19 09:24: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 CD39121F8B7E for ; Tue, 19 Feb 2013 09:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 SmGKAGhIlvSA for ; Tue, 19 Feb 2013 09:24:31 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id CCF8821F8B88 for ; Tue, 19 Feb 2013 09:24:30 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id hg5so1946892qab.20 for ; Tue, 19 Feb 2013 09:24:27 -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:content-type; bh=WKqGmqYd/1j5jpFyQdvbl+htwrOIzMWEDxUMCRgwcxI=; b=lcKzfTnAj4Gms2YZCAnwtQ8ze81j1QQBJ+eMvFfqmwoPdmSc2vNjgC+e1Qr0w0cSxR v6fuqr9qKuQYW6CuMDv4cSRyFGheJaebnvQGw23rBBC97lxmkFV8xkiyF9qW3RR8dWN/ dURYdSszCZUsirI5Up8XG876Xns/G4CLSDJpRPgnac4GIjEkQK3gBpBOL45+4Vj+ZcqH LikIxKsY9O1+luqqShBJVIUxxZvMG4gf4fwRWbi86eCylIGjLxo3nPrV4VQxQQEdMqu/ /xNZ/7rzPpEM9RPOX6OzRUBhw5CZTJ/NhE/9myx00ADu13f/eRdVnzmCLZ0klvu/jWzV EclA== MIME-Version: 1.0 X-Received: by 10.49.96.33 with SMTP id dp1mr7873015qeb.60.1361294667433; Tue, 19 Feb 2013 09:24:27 -0800 (PST) Received: by 10.49.131.199 with HTTP; Tue, 19 Feb 2013 09:24:27 -0800 (PST) In-Reply-To: References: <1051713226.2950775.1360964358731.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Tue, 19 Feb 2013 11:24:27 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] Doodle: Link for poll "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: Tue, 19 Feb 2013 17:24:46 -0000 Given that I just found out that the week we will be in Orlando is one of the top 4 busiest weeks of the year for WDW, I think I will likely need to make a reservation much earlier. So, if folks could please respond by next Wednesday, Feb. 27th, that would be helpful. Thanks, Mary. On Fri, Feb 15, 2013 at 3:42 PM, Mary Barnes wrote: > Hi all, > > As usual, we would like to organize a dinner for CLUE WG participants > (unhosted). At this point, it looks like Monday or Wed are best for > me. If folks could please respond no later than Friday, March 7th, so > I can confirm a location that can support the group size. > http://www.doodle.com/xaqdxztxrpt8h6wq > > Note that the time is based on the ending time for the plenaries which > are way too long IMHO, but given the change in guard and the topic for > the technical plenary, it's probably worthwhile to attend. > > Thanks, > Mary. From internet-drafts@ietf.org Thu Feb 21 15:24: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 BA15221F891C; Thu, 21 Feb 2013 15:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 L5eNpVZgQVZz; Thu, 21 Feb 2013 15:24:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3380F21E803F; Thu, 21 Feb 2013 15:24:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221232413.16812.7105.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 15:24:13 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-09.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, 21 Feb 2013 23:24:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-09.txt Pages : 50 Date : 2013-02-21 Abstract: This document offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stewe@stewe.org Thu Feb 21 15:27: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 B6E5321E8044 for ; Thu, 21 Feb 2013 15:27:34 -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, HTML_MESSAGE=0.001, 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 3KD3iXKD7bfY for ; Thu, 21 Feb 2013 15:27:34 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3F21E803D for ; Thu, 21 Feb 2013 15:27:33 -0800 (PST) Received: from mail64-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Feb 2013 23:27:33 +0000 Received: from mail64-ch1 (localhost [127.0.0.1]) by mail64-ch1-R.bigfish.com (Postfix) with ESMTP id 0996E420361 for ; Thu, 21 Feb 2013 23:27:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz936eIc85fh199bIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dh18c673hz2fh2a8h668h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h34h1155h) Received-SPF: pass (mail64-ch1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail64-ch1 (localhost.localdomain [127.0.0.1]) by mail64-ch1 (MessageSwitch) id 136148925155202_23096; Thu, 21 Feb 2013 23:27:31 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail64-ch1.bigfish.com (Postfix) with ESMTP id 0A2BE2005C for ; Thu, 21 Feb 2013 23:27:31 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 21 Feb 2013 23:27:30 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.145]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0263.000; Thu, 21 Feb 2013 23:27:30 +0000 From: Stephan Wenger To: CLUE Thread-Topic: New framework I-D posted Thread-Index: AQHOEIsDKRDSoTZdfE+rJkHvzWf+Nw== Date: Thu, 21 Feb 2013 23:27:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: multipart/mixed; boundary="_004_CD4BED5C94EAAstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: [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, 21 Feb 2013 23:27:34 -0000 --_004_CD4BED5C94EAAstewesteweorg_ Content-Type: multipart/alternative; boundary="_000_CD4BED5C94EAAstewesteweorg_" --_000_CD4BED5C94EAAstewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ques= tions 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 --_000_CD4BED5C94EAAstewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,
Version 9 of the framework I-D is out.  Many editorial changes an= d cleanups, limited new substance.  Included are a number of editor's = notes with questions to the WG, mostly in the context of the ongoing signal= ing discussion (so we will probably not be able to address those questions immediately).
See (some of) you in hellhole Orlando.
Stephan
--_000_CD4BED5C94EAAstewesteweorg_-- --_004_CD4BED5C94EAAstewesteweorg_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Thu, 21 Feb 2013 23:27:29 GMT"; modification-date="Thu, 21 Feb 2013 23:27:29 GMT" Content-ID: Received: from CH1PRD0710HT004.namprd07.prod.outlook.com (10.255.152.39) by BL2PRD0710HT005.namprd07.prod.outlook.com (10.255.102.40) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 21 Feb 2013 23:24:22 +0000 Received: from CH1PRD0710HT003.namprd07.prod.outlook.com (10.255.152.38) by CH1PRD0710HT004.namprd07.prod.outlook.com (10.255.152.39) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 21 Feb 2013 23:24:22 +0000 Received: from mail260-va3-R.bigfish.com (216.32.180.111) by CH1PRD0710HT003.namprd07.prod.outlook.com (10.255.152.38) with Microsoft SMTP Server (TLS) id 14.16.263.1; Thu, 21 Feb 2013 23:24:21 +0000 Received: from mail260-va3 (localhost [127.0.0.1]) by mail260-va3-R.bigfish.com (Postfix) with ESMTP id 9F187680268 for ; Thu, 21 Feb 2013 23:24:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:64.170.98.30;KIP:(null);UIP:(null);IPV:NLI;H:mail.ietf.org;RD:mail.ietf.org;EFVD:NLI X-SpamScore: -20 X-BigFish: ps-20(zz936eIzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2fh668h839h93fhd24h1288h12a5h12a9h12bdh137ah13b6h13eah1441h14ddh1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1664i1155h) Received-SPF: pass (mail260-va3: domain of ietf.org designates 64.170.98.30 as permitted sender) client-ip=64.170.98.30; envelope-from=internet-drafts@ietf.org; helo=mail.ietf.org ;ail.ietf.org ; Received: from mail260-va3 (localhost.localdomain [127.0.0.1]) by mail260-va3 (MessageSwitch) id 1361489059386213_1561; Thu, 21 Feb 2013 23:24:19 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.251]) by mail260-va3.bigfish.com (Postfix) with ESMTP id 5669FF8004C for ; Thu, 21 Feb 2013 23:24:19 +0000 (UTC) Received: from mail.ietf.org (64.170.98.30) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server id 14.1.225.23; Thu, 21 Feb 2013 23:24:14 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07B821E803F; Thu, 21 Feb 2013 15:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 Z0ca366L+2a9; Thu, 21 Feb 2013 15:24:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE4221F8443; Thu, 21 Feb 2013 15:24:13 -0800 (PST) From: To: CC: , Subject: New Version Notification for draft-ietf-clue-framework-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221232413.16812.37742.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 15:24:13 -0800 Return-Path: internet-drafts@ietf.org X-MS-Exchange-Organization-SCL: 1 X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0 X-MS-Exchange-Organization-AuthSource: CH1PRD0710HT003.namprd07.prod.outlook.com X-MS-Exchange-Organization-AuthAs: Anonymous Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 A new version of I-D, draft-ietf-clue-framework-09.txt has been successfully submitted by Stephan Wenger and posted to the IETF repository. Filename: draft-ietf-clue-framework Revision: 09 Title: Framework for Telepresence Multi-Streams Creation date: 2013-02-21 Group: clue Number of pages: 50 URL: http://www.ietf.org/internet-drafts/draft-ietf-clue-framework-09.txt Status: http://datatracker.ietf.org/doc/draft-ietf-clue-framework Htmlized: http://tools.ietf.org/html/draft-ietf-clue-framework-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-09 Abstract: This document offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. The IETF Secretariat --_004_CD4BED5C94EAAstewesteweorg_-- From pkyzivat@alum.mit.edu Sat Feb 23 23:38: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 472AE21F8DDA for ; Sat, 23 Feb 2013 23:38:21 -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 2vSlFqU4uDmo for ; Sat, 23 Feb 2013 23:38:20 -0800 (PST) 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 7481A21F8706 for ; Sat, 23 Feb 2013 23:38:19 -0800 (PST) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 47Zy1l0020b6N64A17eJTo; Sun, 24 Feb 2013 07:38:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([125.122.241.79]) by omta03.emeryville.ca.mail.comcast.net with comcast id 47c91l0011jVNfx8P7cCAn; Sun, 24 Feb 2013 07:36:17 +0000 Message-ID: <5129C2E9.7020400@alum.mit.edu> Date: Sun, 24 Feb 2013 02:36:09 -0500 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 References: In-Reply-To: X-Forwarded-Message-Id: 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=1361691498; bh=MZ+T12BlPAxVZZ2CW1IULSy7kS5QsbHdx8R1HCikfOw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RI+5WloES54m4P+KpCu2NssuBYtLz5NdTYuPLmUvWl9a2JMuXif4dMUBQ3djZrNH0 P7N6WcXnjWM2StQP7n5PpWfTZyQCgXhxYDEPZ775J8R45+aDGgwcIrxAccavSqcb3f EK4M+hoWsmdpoEZHdhRdd3LRbA/+R5X45cKpzo5kskqO+SkWne1eF8g9XK/BVKRaXY sCAZS2g6nBIlsIB3A51DrAP0YFtKHgGHfiZLuJrAELrs+QfEIezSL0UNkx4CLKsEls 9TrSNxOoynymKiShiQOuwz0Fs+GkbsAJc0jv5/ZKGpOELNqWzDgGrEbOYAntoJNsWT +cLQHX8wFDwxw== Subject: [clue] Fwd: RE: [MMUSIC] Another bundling proposal (and why you can't neglect RTP) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Feb 2013 07:38:23 -0000 Roni, Jonathan, and anybody else who cares: There is continued discussion over in MMUSIC about the bundling approach, as well as now bundled things are demultiplexed. Much of that discussion is being driven by rtcweb, but clearly to affects clue as well. If we had a multiplexing scheme over RTP that could be correlated to an m-line within a bundle without being based on either SSRC or payload type, would that be sufficient for both our static and dynamic mappings? (So that we would not need the RTP header extensions.) The main limitation I see is that I don't see how this can accommodate indicating a single RTP stream as satisfying multiple capture-encodings. I'm also not sure how important that is. Thanks, Paul -------- Original Message -------- Subject: RE: [MMUSIC] Another bundling proposal (and why you can't neglect RTP) Date: Sat, 23 Feb 2013 23:14:17 -0800 From: Bernard Aboba To: Paul Kyzivat , "mmusic@ietf.org" Paul said: > I had originally found little reason to pursue > draft-westerlund-avtcore-transport-multiplexing-04, but now I start to > think that this provides an answer to the problem of demuxing without > having to specify SSRCs or restrict payload types. I think it could be > used, rather than an RTP header extension, to specify capture-encodings > for clue. (But it can't specify mapping to multiple capture-encodings.) [BA] Yes, I've also begun to wonder if we haven't been giving that (and possibly) other transport multiplexing approaches insufficient consideration. A/V multiplexing isn't just an SDP issue, it is also an RTP issue. Say we don't specify SSRCs and instead require that the payload type is unique among all multiplexed m= lines so we can use PT to de-multiplex incoming RTP. Without specifying SSRCs, how do we map the RTCP reports, which only include SSRCs and not payload types to the appropriate media stream tracks? It seems to me that Cullen's "Plan A" has a fundamental flaw. From pkyzivat@alum.mit.edu Sun Feb 24 15:20: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 97B8821F911A for ; Sun, 24 Feb 2013 15:20:43 -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 XyNhbkYfKCIj for ; Sun, 24 Feb 2013 15:20:42 -0800 (PST) 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 1595921F910A for ; Sun, 24 Feb 2013 15:20:38 -0800 (PST) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 4H4b1l0081zF43QA1PLeVD; Sun, 24 Feb 2013 23:20:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([115.198.251.22]) by omta24.emeryville.ca.mail.comcast.net with comcast id 4PJF1l00U0VlArX8kPJNCF; Sun, 24 Feb 2013 23:18:33 +0000 Message-ID: <512A9240.3040800@alum.mit.edu> Date: Mon, 25 Feb 2013 06:20: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: 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=1361748038; bh=42b1R+8LcOqGJe3mnWq6sJb8HSc8AXzzFJm6Xn2cv+U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hHLbSmBJ6bIjenfQEx8kTu7Bw+9bnDWZRWOxR36C2dgw27iz0+AHi+dn6nDLNmVDP quTP2L2tsksZqr40azjqbWGDeUbwOFBvty3xoZ5WIaOoggx18NTf8q9eNsH3vO0svJ UibG28+jxikVqPQGZ0xNHSgLarR5doUUH06oPCp8dnBsPuwH2EiOGx6HNR2Wrx5q3Q 4/cyVd89e0t7GddMxaHNZvmenjK3lG1wnT+tmtYDI1mCsRj5RkOgT+0F19m98FhQhG zTF2jcHFxUIA5dazRb/pJNEvNRkxQqQNdS8Hkbdyich7oQQ0hTolnqeTAWebT9opCG ADpYG2H4gUQJQ== 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: Sun, 24 Feb 2013 23:20:43 -0000 Stephan, Thanks for doing this. I think the document is much improved. I have a few comments: Definition of Encoding: 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." This is fine as far as it goes, but I don't think it captures the full semantics. According to this definition, I would expect that I could apply an encoding 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: "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." In section 4: 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. 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. Section 6.2: 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). 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 are spatially related. I have another question related to this section, but unrelated to the recent changes: 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. This would be clearer if scene entries contained captures of all media types. But I realize doing that may greatly increase the number of entries. 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.) Section 8: IMO a small bit of this content could be deferred to the data model: Each Capture has an Encoding Group attribute. The value of this attribute is the encodeGroupID for the Encoding Group with which it is associated. Section 9: 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. 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.) OPEN ISSUE 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. This would be clearer if scene entries contained captures of all media types. But I realize doing that may greatly increase the number of entries. Thanks, Paul (as individual) From mary.ietf.barnes@gmail.com Mon Feb 25 06:18: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 44BDA21F9300 for ; Mon, 25 Feb 2013 06:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 GHM44Cj-rliA for ; Mon, 25 Feb 2013 06:18:53 -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 B65FB21F92FE for ; Mon, 25 Feb 2013 06:18:53 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id g10so1587066qah.11 for ; Mon, 25 Feb 2013 06:18:53 -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=XP97hvjU9gd9pfw7PKbgWWxO4eRBnt0j0dTDfbd9WGA=; b=NMWmnrWZjnjjZNq8D2LkvEICz2zScbZoq5wU5zGaNv7ybiyhRRR+/6Fkj6+xTOD6/I +DLEdVF10JWSV1HjVgcDiXIglCOwlRMilTOlPM8nxRDHE4eSAzNd85EysRdin4PaAkKF qBJYjq0OvOIGy2rQAAvGGp8z8SBOMf5bGNQlgN3PledibTU5O/On7rfgRJNAwuJMiVik GB9mo89OAh/ZUYUWSLGyowzw2WxYIk46Y04QtLcdFW9aolRdqitK46DBfRBYB6042FjC a4GrzmcEC+5rtkkiOMn2iKT7CLRdlexbmkW7StEcTd35d1PVqz7id2ePP7ueOhTB10cz CJ1w== MIME-Version: 1.0 X-Received: by 10.49.85.34 with SMTP id e2mr10442032qez.1.1361801933236; Mon, 25 Feb 2013 06:18:53 -0800 (PST) Received: by 10.49.24.130 with HTTP; Mon, 25 Feb 2013 06:18:53 -0800 (PST) Date: Mon, 25 Feb 2013 08:18:53 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] No CLUE Design Team meeting Today: Feb. 25th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 14:18:54 -0000 Hi all, Given the draft deadline and the fact that everyone is likely furiously typing today, we will not have a meeting. We should definitely have one next week as prep for the IETF meeting. We'll have a draft agenda out on Wednesday Feb. 27th. If you have not contacted the chairs with a specific agenda request, then please do so by 5pm Pacific on Tuesday, Feb. 26th. We will of course allocate time for each of the main topics, and will fit the appropriate drafts into those slots. Regards, Mary. From mary.ietf.barnes@gmail.com Tue Feb 26 09:47: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 7132821F8795 for ; Tue, 26 Feb 2013 09:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 KhFHWR3dD-cH for ; Tue, 26 Feb 2013 09:47:06 -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 72FCC21F8718 for ; Tue, 26 Feb 2013 09:47:06 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id cr7so2624700qab.8 for ; Tue, 26 Feb 2013 09:47:05 -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=bfvQ3+h4N+XLsCtL9vARPI0E3vpDmng9Tg1FTdXR4qo=; b=XFQlp6xi2neTF52oo9uaGO5jssSnIc8/0yq4TuIkQSAcDpWpXtPT1jS/N2fDLEufqj O9v4fBc/pdhqPgPosh/mwQaMJK9fk0OMEXFammnNgtle+9ywrjwV1JFPmEr6/Ztm9242 AYTbgybdUhhEZ/ReV6Ln1pSq7cPPWYGVpmDYcZwJ0MJHn22Qco/mcAbknaAx+SUpZbBc ZyTutSPTAbE1IueNX9udZrLhri0PLdsGEKazj2fr/2v2ksk7vGfLzQiujdc5yiRYYZEj AzR01/CqWrWgRVhyKn6GEuMZNUxIZUUlb87zksTODFlWNqIodS3CAUek7bLC1AWGhDIB EC9g== MIME-Version: 1.0 X-Received: by 10.49.127.139 with SMTP id ng11mr21292553qeb.54.1361900825890; Tue, 26 Feb 2013 09:47:05 -0800 (PST) Received: by 10.49.24.130 with HTTP; Tue, 26 Feb 2013 09:47:05 -0800 (PST) In-Reply-To: References: Date: Tue, 26 Feb 2013 11:47:05 -0600 Message-ID: From: Mary Barnes To: Samuel Weiler Content-Type: text/plain; charset=ISO-8859-1 Cc: CLUE , Bernard Aboba Subject: Re: [clue] jefsey can post to the architecture list? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 17:47:07 -0000 Yeah - I had asked Bernard about this and hadn't gotten a response. Cindy must have let it through without realizing. I can go in and blacklist him if that's the appropriate thing to do. Mary. On Tue, Feb 26, 2013 at 11:45 AM, Samuel Weiler wrote: > I was startled to see a post from JFC Morfin on the architecture-discuss > list. > > As a reminder, JFC is one of two individuals subject to an RFC 3683 posting > rights action. http://www.ietf.org/iesg/pr-action.html > > Feel free to block him. :-) > > -- Sam > From mary.ietf.barnes@gmail.com Tue Feb 26 15:09: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 D94F821F86EA for ; Tue, 26 Feb 2013 15:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.578 X-Spam-Level: X-Spam-Status: No, score=-103.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 nMR87VifI1zQ for ; Tue, 26 Feb 2013 15:09:38 -0800 (PST) Received: from mail-qe0-f44.google.com (mail-qe0-f44.google.com [209.85.128.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEDD521F86E3 for ; Tue, 26 Feb 2013 15:09:38 -0800 (PST) Received: by mail-qe0-f44.google.com with SMTP id x7so2016738qeu.31 for ; Tue, 26 Feb 2013 15:09:29 -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=S2JVjQ7bnzLUGksMIRIeTgeZrTgcWXddPiPkiILB6ak=; b=vJpMP1WNGQnLSn1jIIJDZ1wX/MTPsOcRSgWqpfCZ7RXRXxoMGijodzOfJPXptcdVhq MZozoYt1L/K9ZrL2cKlTvt/5PNatDogsZCgeHVip+0+TTZhVORYme7Bqf6H5rcAGW6z7 xObctM85nPqMJa3tnEv9nt2+DUjTys3WGNL+3p9H0FgpIbxA7jw+5jwml3XYU8VTJU5n sOABh8N0Thk0lbPp1vewGNg3qO63+Br9xotr02ry1OmxZk7MeXmJ5f0sqt3gmZB6Nfit gsn/HvcuHgUhWnD3Gaa+PkBnXKITb+eS6Vdvtxh7OlXhuye/SLbqy1C8fGyVzRsLng+r ocLw== MIME-Version: 1.0 X-Received: by 10.224.106.201 with SMTP id y9mr4866051qao.3.1361920169114; Tue, 26 Feb 2013 15:09:29 -0800 (PST) Received: by 10.49.24.130 with HTTP; Tue, 26 Feb 2013 15:09:29 -0800 (PST) Date: Tue, 26 Feb 2013 17:09:29 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] IETF-86 CLUE WG reminders X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 23:09:40 -0000 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. From christer.holmberg@ericsson.com Wed Feb 27 02:24: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 1A05621F850C for ; Wed, 27 Feb 2013 02:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 hhbImqsV5hrG for ; Wed, 27 Feb 2013 02:24:55 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C029021F8481 for ; Wed, 27 Feb 2013 02:24:54 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-98-512ddef41ac5 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B6.6B.10459.4FEDD215; Wed, 27 Feb 2013 11:24:52 +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, 27 Feb 2013 11:24:52 +0100 From: Christer Holmberg To: Mary Barnes , CLUE Thread-Topic: [clue] IETF-86 CLUE WG reminders Thread-Index: AQHOFHZc4cRwUS6bc0+S2jGrgngco5iNf0ww Date: Wed, 27 Feb 2013 10:24:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10AF4B@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvje6Xe7qBBntvGlrsP3WZ2eLz/v3M DkweO2fdZfdYsuQnUwBTFJdNSmpOZllqkb5dAlfGjqd32AoOc1Qs/LKatYHxOlsXIyeHhICJ xPe/M5ghbDGJC/fWA8W5OIQEDjFKbHr9nwnCWcwo8W9FL1AVBwebgIVE9z9tkAYRASeJCy/f s4DYwgK6Epd2trBCxPUkFu/fwA5hG0mcOvQXLM4ioCqxbfp+sHpeAW+JX1NegS0WEgiQOLz6 OhOIzSkQKPF8/mSwekagg76fWgMWZxYQl7j1ZD4TxKECEkv2nIc6WlTi5eN/rBC2osTV6cuh 6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMnvdxw EyMwFg5u+a27g/HUOZFDjNIcLErivGGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MPra 6OXpb1S/celpv9ehtsw/ZfkFfB9KLXiCWjyl/LiMv1c3+pY2N6WZVYQuslkas+IIx8sU96nc FQVf1cz/TTnVcJnRzNVTmz2O56LBl3zRy/c2pW18vOXjbeZPMaxeRkfk1ZMlm5RuZPhtiZqU /23d/d/buO9Ud7e5vnBclnft7qrXu/43K7EUZyQaajEXFScCAJku4U1TAgAA Subject: Re: [clue] IETF-86 CLUE WG reminders X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 10:24:56 -0000 Hi, >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 Orlan= do time). I had missed the doodle, but I just added my input (any of the suggested ti= mes is ok for me). >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=20 >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=20 >for each but I think we need more for a productive meeting and we'd certai= nly welcome others for dinner ;) I added my input for dinner also, but at the moment both times are yellow. = However, feel free to count me in - I will be able to indicate whether I ca= n make it or not well in advance before the dinner. Regards, Christer From roberta.presta@unina.it Wed Feb 27 10:40: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 3C4A521F896B for ; Wed, 27 Feb 2013 10:40:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O13oKG-VvMB7 for ; Wed, 27 Feb 2013 10:40:45 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 160D421F88D1 for ; Wed, 27 Feb 2013 10:40:41 -0800 (PST) Received: from [127.0.0.1] ([10.219.50.110]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r1RIebvk016180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 19:40:38 +0100 Message-ID: <512E532B.7000107@unina.it> Date: Wed, 27 Feb 2013 19:40:43 +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: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130227-0, 27/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [clue] data model - ongoing work X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 18:40:47 -0000 Hi all, a new version of the data model document will be soon available. The to-be-moved parts of the framework document (marked with BEGIN OUTSOURCE and END OUTSOURCE in the document) have been copied into the data model document. The data model XML Schema has been restructured. It is now conceived as a list of type definitions (no more envelope). This fits better the role of the data model and makes it more independent from the protocol message definition. Protocol message definitions may use ad-hoc defined XML envelopes containing the desired information described in the datamodel (like, for example, an or a envelope). With this idea in mind, we are currently defining a element representing the concept of capture encoding as defined in the framework. It contains a reference to a media capture and one ore more individual encodings, each one characterized by the consumer's desired parameters (as envisioned in par 9 page 32 of the framework-09 version). At a high level of abstraction, Advertisement and Configure could be structured as: *** ... ... ... ... ... *** ==> the list of capture encodings The *** part could be filled with to-be-defined elements and attributes taking into account sequence numbers, origin, and other information needed by the protocol. Due to the fact that the cut-off date has just expired, we will post the updated draft on a temporary server here at our university. I'll send you the link in an upcoming email. Comments are welcome, Roberta -- 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 From roberta.presta@unina.it Wed Feb 27 10:47: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 16EDA21F89A6 for ; Wed, 27 Feb 2013 10:47:06 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTdzvH9RMZCd for ; Wed, 27 Feb 2013 10:47:05 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2635F21F89D3 for ; Wed, 27 Feb 2013 10:47:04 -0800 (PST) Received: from [127.0.0.1] ([10.219.50.110]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r1RIl3SJ025871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 19:47:04 +0100 Message-ID: <512E54AD.9090707@unina.it> Date: Wed, 27 Feb 2013 19:47:09 +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: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130227-0, 27/02/2013), Outbound message X-Antivirus-Status: Clean Subject: [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, 27 Feb 2013 18:47:06 -0000 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 From pkyzivat@alum.mit.edu Wed Feb 27 14: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 D53A021F84A1 for ; Wed, 27 Feb 2013 14: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 rfaXZJvVhuNQ for ; Wed, 27 Feb 2013 14:28:20 -0800 (PST) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:227]) by ietfa.amsl.com (Postfix) with ESMTP id 369C621F846E for ; Wed, 27 Feb 2013 14:28:20 -0800 (PST) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta12.emeryville.ca.mail.comcast.net with comcast id 5Rqg1l00D1GXsucACaULSW; Wed, 27 Feb 2013 22:28:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([115.193.211.231]) by omta07.emeryville.ca.mail.comcast.net with comcast id 5aSA1l00J506YvF8UaSDtx; Wed, 27 Feb 2013 22:26:17 +0000 Message-ID: <512E8805.1020409@alum.mit.edu> Date: Thu, 28 Feb 2013 06:26:13 +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: <512E532B.7000107@unina.it> In-Reply-To: <512E532B.7000107@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=1362004100; bh=wr/Yn9QsVBDBrCplthHXZn/A35zMuzqBU+cDrF9zIzk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VtJDNuTD/e6ZKSynYJdEjkHHq0LmevCEoeLuguw5PhYj7Xg0hFmQ9H64X18dq8z67 l2JX4wOeKNs55BKf5zsE98I/XAFFGVAtxGndl+iYLzaYCcg+PA8DpNpmbkTqO5XzEG zxFJcvLJ1zHPga4M5r/V68fpAZan4WZ17U0tAsnMzlCLnoY7Zjc8q3co1MTGex0NdY IHalx5a7kSqBuDBlt8Rdo/qgQesqcqCMU4ECu/e546YUbXy8Jb/ANcYKg2Vd7y6SUp tKw16tBIdRJ1CUvWpfqaMUGotYsKRJ8Y8Epyqxfk4enNp5Ve3E+HbdoF9hTgZCh+h7 pUPyirNTZc/6w== Subject: Re: [clue] data model - ongoing work X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 22:28:20 -0000 Hi Roberta, This sounds great. One question below. On 2/28/13 2:40 AM, Roberta Presta wrote: > Hi all, > > a new version of the data model document will be soon available. > The to-be-moved parts of the framework document (marked with BEGIN > OUTSOURCE and END OUTSOURCE in the document) have been copied into the > data model document. > > The data model XML Schema has been restructured. > It is now conceived as a list of type definitions (no more > envelope). > This fits better the role of the data model and makes it more > independent from the protocol message definition. > Protocol message definitions may use ad-hoc defined XML envelopes > containing the desired information described in the datamodel (like, for > example, an or a envelope). > > With this idea in mind, we are currently defining a > element representing the concept of capture encoding as defined in the > framework. It contains a reference to a media capture and one ore more > individual encodings, each one characterized by the consumer's desired > parameters (as envisioned in par 9 page 32 of the framework-09 version). Why would a single capture-encoding reference more than one encoding? If that is for multicast, then I would expect each encoding to result in a separate capture-encoding. Thanks, Paul > At a high level of abstraction, Advertisement and Configure could be > structured as: > > > *** > ... > ... > ... > ... > ... > > > > *** > ==> the list of capture encodings > > > > The *** part could be filled with to-be-defined elements and attributes > taking into account sequence numbers, origin, and other information > needed by the protocol. > > Due to the fact that the cut-off date has just expired, we will post the > updated draft on a temporary server here at our university. > I'll send you the link in an upcoming email. > > Comments are welcome, > > Roberta > From mary.ietf.barnes@gmail.com Wed Feb 27 15:18: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 E898121F8461 for ; Wed, 27 Feb 2013 15:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 59Nv1+VaQVsP for ; Wed, 27 Feb 2013 15:18:24 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B71AB21F845F for ; Wed, 27 Feb 2013 15:18:24 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id cr7so921702qab.17 for ; Wed, 27 Feb 2013 15:18:23 -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=qVEq8llzwG2jIsBpsvKDvoe68vCIeZKXLNNpmKSaAPk=; b=HnNxR6ZBujmx/obJ5cHg86IirERms1sGTDOsQ8T2vBKFdTcYrMcbDrBDEC86E2bH/p CUWOD1LmxxWdxKxzqEx8gSutT0lvSYAoPG9H++owbk+g8zzT/yXjHoFo6SeljjiwKI0r YV+Kr3d7R5NqyrPmyYixGtkFz2ZsB3FCezIfGlvvZ+VCZTQidCAOJC5oNHi0iz2l/0LR pqDhQjHRan6c93us8LSfGwlQHoq1/VOcHzoiiyMFq5fzIeHE3nMKw9WzBm4c3ytOZwAO 7CMtf4e/T7M404OB/bqjI02mFT/PWz+94EZWAHm+Gpiut85aT1IfMiE5Y6wjkumHndxS 1txg== MIME-Version: 1.0 X-Received: by 10.229.171.3 with SMTP id f3mr1503678qcz.41.1362007103067; Wed, 27 Feb 2013 15:18:23 -0800 (PST) Received: by 10.49.24.130 with HTTP; Wed, 27 Feb 2013 15:18:22 -0800 (PST) Date: Wed, 27 Feb 2013 17:18:22 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [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: Wed, 27 Feb 2013 23:18:26 -0000 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 wrote: > 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. From mary.ietf.barnes@gmail.com Wed Feb 27 15: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 D972121F8BA7 for ; Wed, 27 Feb 2013 15:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 427byrz-syqb for ; Wed, 27 Feb 2013 15:50:02 -0800 (PST) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 827D921F87D7 for ; Wed, 27 Feb 2013 15:46:19 -0800 (PST) Received: by mail-qe0-f47.google.com with SMTP id q19so976253qeb.34 for ; Wed, 27 Feb 2013 15:46:18 -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=/uqFdOD96EWVjNvDVhDxoZ9zK0OXRB3bcpjJ0hTys68=; b=WxvhjQUl2d1pBXcVV9hy+aFGVSNU2XDUSTM4kHpmHc/6+RyKfGWXKhkUU3NKy8/YTc FxTGnLL0UfNl2FOl2Z/5lrnGpZlzsekVuk3bXTgEnX2EfOq8vaTtUnoAOQ4JcMGOSoMi fgRSzlVbWXrzoK6ePKNz1X/ejMA6dfkfC2E8QC+6qjkkrOmXZ52KZAfciHNgW67VZnQG CKjo9h0XolOV3UVX4o+hEl/i/5YbVPFOZRHmKITsNUP09MXaaG0bUW7yqFnZVLw/HPVV p+cbshrFfCuqjv0/RsNuUwswunj0JAfkNJrKjyXl3LLxhkKqEl87X0eCCkrIiZVgArwF OukA== MIME-Version: 1.0 X-Received: by 10.49.29.135 with SMTP id k7mr7407155qeh.39.1362008778792; Wed, 27 Feb 2013 15:46:18 -0800 (PST) Received: by 10.49.24.130 with HTTP; Wed, 27 Feb 2013 15:46:18 -0800 (PST) Date: Wed, 27 Feb 2013 17:46:18 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Draft agenda for CLUE at IETF-86 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Feb 2013 23:50:22 -0000 A draft agenda has been uploaded for the CLUE WG sessions at IETF-86: https://datatracker.ietf.org/meeting/86/agenda/clue/ Note that the MMUSIC WG is meeting on Tuesday: https://datatracker.ietf.org/meeting/86/agenda/mmusic/ It would be extremely helpful for folks to understand the context of some of the discussions in the CLUE WG on Thursday if you attend those sessions. And, as usual we will refine the Thursday agenda based on the Monday discussions as well as design team discussions. Please post any questions or comments for clarification no later than noon Pacific on Friday, March 1st. Thanks, Mary. From Christian.Groves@nteczone.com Wed Feb 27 20:01: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 66C8421F8A6B for ; Wed, 27 Feb 2013 20:01:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N4wKENNN6My for ; Wed, 27 Feb 2013 20:01:31 -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 1FC0721F8A67 for ; Wed, 27 Feb 2013 20:01:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEDWLlF20U5n/2dsb2JhbAANOMIvgRODEgEBBTgbKwsLGAklDwJGEwgBARe2CpNXjU0GgUiDQAOTAJdHgVUJ Received: from ppp118-209-78-103.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.78.103]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Feb 2013 14:30:43 +1030 Message-ID: <512ED663.80103@nteczone.com> Date: Thu, 28 Feb 2013 15:00: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: <512E54AD.9090707@unina.it> In-Reply-To: <512E54AD.9090707@unina.it> 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, 28 Feb 2013 04:01:32 -0000 Hello Roberta, Please see my comments below. Regards, Christian On 28/02/2013 5:47 AM, Roberta Presta wrote: > 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. [CNG] I agree that there could be several difference reasons why the Advertiser might indicate that there is a simultaneity limitations. It could also relate to scene composition issues, i.e. if a movable device is capturing different regions in the advertised captures. Think would a device physical constraint rather than a transmission physical constraint. I think the main thing is that the reason to send a simultaneity constraint is not limited. > > 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. [CNG] Do we need the text "(though it may not make sense to do so)"? If the consumer chooses a "strange" set of captures then it should make sense to it. It may not make sense to an Advertiser. Also do we need "physically", i.e. is it sufficient to say "...that could be transmitted at the same time." > > 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?) [CNG] I'm not sure what you mean by "in almost one of the listed ones." I think the intention is that the selected captures firstly meet a "capture scene entry" and then the "simultaneous set" if they don't. If the consumer can't get a match then I guess there would be a failure. Maybe we need an additional error in Paul K's signalling document for a Configure message? i.e. "Unable to select captures due to local constraints" > > 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. [CNG] My understanding is that a CSE is under a capture scene? I'm not sure how the above examples relate to that. > > > 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. [CNG] There's probably a thesis for someone to study whether inclusion or exclusion is best. I guess the tradeoff of less signalling data is possibly more processing to determine whether the Consumers choice fits. > > 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)." [CNG] I'm for keeping things simple and assuming "or". If we define robust version/extension mechanisms if we find its a issue we could enhance CLUE by having more extension syntax. > > Do you think we should stuck on the framework solution or also > consider the aforementioned alternatives? > I promise I stop thinking about it! [CNG] Don't stop thinking about it. It's good that its being questioned, that leads to a better protocol. > > RP > From Christian.Groves@nteczone.com Wed Feb 27 22:19: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 CCD8B21F84D9 for ; Wed, 27 Feb 2013 22:19:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3kuj7HEWi-E for ; Wed, 27 Feb 2013 22:19:54 -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 CC18D21F84C1 for ; Wed, 27 Feb 2013 22:19:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAGz2LlF20U5n/2dsb2JhbAANOMIvgRCDEgEBAQQBAQE1GxsKEQsYCRYPCQMCAQIBFTAGDQYCAQEViAauAJNGBI1NgU6DQAOqR4FV Received: from ppp118-209-78-103.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.78.103]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Feb 2013 16:49:52 +1030 Message-ID: <512EF700.2080207@nteczone.com> Date: Thu, 28 Feb 2013 17:19:44 +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 References: In-Reply-To: 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, 28 Feb 2013 06:19:55 -0000 Hello all, 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". 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." 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. 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? 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. 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? 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. 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. Section 6.1.1: Area of capture: for consistency we should probably use "bottom camera left", "top camera right", etc... 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. 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? 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? Section 7.1 Pg26.: We can probably remove "Clue-protocol internal information" from the list of video codec specific parameters. 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. 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. Section 10.: It is envisaged that CLUE could support non-RTP streams in the future? Section 11.1.1 Fig. : Nit - the figure has D but the text talks about 'd'. Regards, Christian 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 From Christian.Groves@nteczone.com Wed Feb 27 22:39: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 7E30321F84AE for ; Wed, 27 Feb 2013 22:39:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBoy40ttIUZS for ; Wed, 27 Feb 2013 22:39:51 -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 4C2AC21F84AD for ; Wed, 27 Feb 2013 22:39:51 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEH6LlF20U5n/2dsb2JhbAANOMIvgRCDEgEBAQQBAQEkERsbChELGAkWDwkDAgECARUwEwYCAQGIG64Ck0UEjxsWgyoDqkc Received: from ppp118-209-78-103.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.78.103]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Feb 2013 17:09:50 +1030 Message-ID: <512EFBB1.2020603@nteczone.com> Date: Thu, 28 Feb 2013 17:39:45 +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: <5122892C.6000804@cisco.com> In-Reply-To: <5122892C.6000804@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: Thu, 28 Feb 2013 06:39:52 -0000 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 > From Christian.Groves@nteczone.com Wed Feb 27 22:47: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 2688F21F8ACE for ; Wed, 27 Feb 2013 22:47: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-+rY8nBibYx for ; Wed, 27 Feb 2013 22:47: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 5927A21F855A for ; Wed, 27 Feb 2013 22:47:28 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAv9LlF20U5n/2dsb2JhbAANOMIvgRGDEgEBAQQBAQE1GxsKEQsYCRYPCQMCAQIBFTATBgIBAYgbrgGTRgSNU4FIFoMqA6pHgV4 Received: from ppp118-209-78-103.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.78.103]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Feb 2013 17:17:27 +1030 Message-ID: <512EFD7B.7030504@nteczone.com> Date: Thu, 28 Feb 2013 17:47:23 +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: <510D4F2B.2010304@unina.it> In-Reply-To: <510D4F2B.2010304@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] clue data model updates - new version available (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: Thu, 28 Feb 2013 06:47:29 -0000 Hello Roberta & Simon, Obviously I support the addition of the attributes :-). 01 of my draft provides some updates. I see there's an agenda item for Orlando to discuss the capture attributes. Its probably best to align with the framework then. Regards, Christian On 3/02/2013 4:38 AM, Roberta Presta wrote: > Hi all, > > we have just uploaded a new version of the data model draft. > > We have added some attributes proposed in draft-groves-capture-attr-00: > - priority > - embedded text > - language > - dynamic > - language > - a new element used in place of "supplementary information" > () > > We have not added yet "view", "role" and "presentation". We have left > "content" to describe the content of a capture. > It seems to us that no final consensus has been reached about all of > them, since mail threads have been left pending. > Nonetheless, we believe the definition of keywords can help the > capture selection process on the consumer side, but further discussion > is needed to define them. > > We have moved out from the blob the description of the > available media captures again. > Indeed, media captures should have identifiers that are valid out of > the local scope of capture scenes, since a consumer should be able to > request also single captures in the CONFIGURE message. In each media > capture, a reference to the capture scene containing it is provided. > It identifies the space the spatial information of the media capture > refers to. > > Comments are welcome. > Cheers, > > Roberta & Simon > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Feb 27 23:27: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 9332421F8B33 for ; Wed, 27 Feb 2013 23:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.252 X-Spam-Level: X-Spam-Status: No, score=-6.252 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 zs47QpPmPOLi for ; Wed, 27 Feb 2013 23:27:22 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0C021F8AF2 for ; Wed, 27 Feb 2013 23:27:22 -0800 (PST) X-AuditID: c1b4fb30-b7f0d6d000007e61-0e-512f06d920c7 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2B.B9.32353.9D60F215; Thu, 28 Feb 2013 08:27:21 +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, 28 Feb 2013 08:27:21 +0100 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-02.txt - Christer's two initial comments Thread-Index: Ac4VhQsczWWWPkmOShKZlDhfuGf6Hg== Date: Thu, 28 Feb 2013 07:27:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10BA4D@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvje5NNv1Ag8YTMhb7T11mtlix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx/dULloLNUhUvrm5na2DcJtrFyMkhIWAi cXDuc3YIW0ziwr31bF2MXBxCAocYJS6vP80E4SxmlJjxuY21i5GDg03AQqL7nzZIg4iAp8SO j1OYQWxhgVqJiVNvgZWICNRJnO+ygyjRk3j6ZicjiM0ioCqx6c1GsHJeAW+JTY/WgcUZgfZ+ P7WGCcRmFhCXuPVkPhPEPQISS/acZ4awRSVePv7HCmErSlydvhyqXkdiwe5PbBC2tsSyha+h 5gtKnJz5hGUCo/AsJGNnIWmZhaRlFpKWBYwsqxjZcxMzc9LLzTcxAgP74JbfBjsYN90XO8Qo zcGiJM4b7nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj+Vs7t3Xx9l6aj59+KNmdtvZ8 5tSt5Z9/BN8uPm/xX9rp8FL7k+JRHZxn45373Y/+XFC6y9xpromY/tbd5TJ1Vdb6e6rPv1+o 48zG8MdtydFVE13dm7akfpnx8po0g+1niXilxzu1+GX3VDWpyL8N/PhM7OAn/8mn67Yo3zDo Nc8P+2A/dVWWEktxRqKhFnNRcSIAq+S9NToCAAA= Subject: Re: [clue] Fwd: New Version Notification for draft-kyzivat-clue-signaling-02.txt - Christer's two initial comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 07:27:23 -0000 Hi Paul, A couple of initial comments on the draft: ----------------- Q1: General: The draft seems to assume that a CONFIGURE transaction takes p= lace before the associated media capabilities is negotiated, e.g. using a r= e-INVITE. We have discussed before what comes first, SDP Offer or CONFIGURE= , and I have previously stated that a CONFIGURE must always be aligned with= currently negotiated media capabilities. However, when thinking more about it, it perhaps makes sense to do the CONF= IGURE first, because it allows the endpoints to agree on what to do, which = then makes it easier to construct an SDP Offer to negotiate the media capab= ilities needed for that configuration. ----------------- Q2: In section 5.1.2., there is a re-INVITE sent, in order to negotiate a "= pre-determined bulk of media streams". But, in case those media streams wer= e provided already in the first offer, there is no need to re-negotiate.=20 ----------------- Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Pau= l Kyzivat Sent: 18. helmikuuta 2013 23:43 To: clue@ietf.org Subject: Re: [clue] Fwd: New Version Notification for draft-kyzivat-clue-si= gnaling-02.txt IMO there is now sufficient "meat" here to have some serious discussion amo= ng the intended authors about which way we want to go on many things. So please start shooting. Thanks, Paul On 2/18/13 4:16 PM, Paul Kyzivat wrote: > I just posted the -02 version. > There is now a history section that summarized the changes. > Basically this includes a bunch of proposals by me and co-workers. > Please consider these straw-horses. > > Thanks, > Paul > > > -------- Original Message -------- > Subject: New Version Notification for=20 > draft-kyzivat-clue-signaling-02.txt > Date: Mon, 18 Feb 2013 13:01:47 -0800 > From: internet-drafts@ietf.org > To: pkyzivat@alum.mit.edu > CC: lennard.xiao@huawei.com, christian.groves@nteczone.com > > > A new version of I-D, draft-kyzivat-clue-signaling-02.txt > has been successfully submitted by Paul Kyzivat and posted to the IETF=20 > repository. > > Filename: draft-kyzivat-clue-signaling > Revision: 02 > Title: CLUE Signaling > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 21 > URL: > http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-02.tx > t > Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling > Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-= 02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kyzivat-clue-signaling-02 > > Abstract: > This document specifies how signaling is conducted in the course of > CLUE sessions. This includes how SIP/SDP signaling is applied to > CLUE sessions as well as defining a CLUE-specific signaling protocol > that complements SIP/SDP and supports negotiation of CLUE application > level data. > > > > > > The IETF Secretariat > > > > > _______________________________________________ > 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 Thu Feb 28 02:56: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 435B421F8AF2 for ; Thu, 28 Feb 2013 02:56:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBHPhsL-dIS0 for ; Thu, 28 Feb 2013 02:56:21 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id BEB2F21F84C2 for ; Thu, 28 Feb 2013 02:56:15 -0800 (PST) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r1SAtjn1028012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Feb 2013 11:56:14 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_674C3591-6CF7-4766-9182-6F9BA12684D3" From: Simon Pietro Romano In-Reply-To: <512EFD7B.7030504@nteczone.com> Date: Thu, 28 Feb 2013 11:56:16 +0100 Message-Id: <859D06B6-645B-4523-8837-EF3A07FE2769@unina.it> References: <510D4F2B.2010304@unina.it> <512EFD7B.7030504@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.1283) Cc: clue@ietf.org Subject: Re: [clue] clue data model updates - new version available (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: Thu, 28 Feb 2013 10:56:22 -0000 --Apple-Mail=_674C3591-6CF7-4766-9182-6F9BA12684D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sure. Let's discuss this in Orlando. Cheers, Simon Il giorno 28/feb/2013, alle ore 07:47, Christian Groves ha scritto: > Hello Roberta & Simon, >=20 > Obviously I support the addition of the attributes :-). 01 of my draft = provides some updates. I see there's an agenda item for Orlando to = discuss the capture attributes. Its probably best to align with the = framework then. >=20 > Regards, Christian >=20 > On 3/02/2013 4:38 AM, Roberta Presta wrote: >> Hi all, >>=20 >> we have just uploaded a new version of the data model draft. >>=20 >> We have added some attributes proposed in = draft-groves-capture-attr-00: >> - priority >> - embedded text >> - language >> - dynamic >> - language >> - a new element used in place of "supplementary information" = () >>=20 >> We have not added yet "view", "role" and "presentation". We have left = "content" to describe the content of a capture. >> It seems to us that no final consensus has been reached about all of = them, since mail threads have been left pending. >> Nonetheless, we believe the definition of keywords can help the = capture selection process on the consumer side, but further discussion = is needed to define them. >>=20 >> We have moved out from the blob the description of the = available media captures again. >> Indeed, media captures should have identifiers that are valid out of = the local scope of capture scenes, since a consumer should be able to = request also single captures in the CONFIGURE message. In each media = capture, a reference to the capture scene containing it is provided. It = identifies the space the spatial information of the media capture refers = to. >>=20 >> Comments are welcome. >> Cheers, >>=20 >> Roberta & Simon >>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( 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=_674C3591-6CF7-4766-9182-6F9BA12684D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Sure. = Let's discuss this in = Orlando.

Cheers,

Simon

Il giorno 28/feb/2013, alle ore 07:47, Christian Groves = ha scritto:

Hello Roberta & Simon,

Obviously I support = the addition of the attributes :-). 01 of my draft provides some = updates. I see there's an agenda item for Orlando to discuss the capture = attributes. Its probably best to align with the framework = then.

Regards, Christian

On 3/02/2013 4:38 AM, Roberta = Presta wrote:
Hi = all,

we have just = uploaded a new version of the data model = draft.

We have added = some attributes proposed in = draft-groves-capture-attr-00:
- = priority
- embedded = text
- = language
- = dynamic
- = language
- a new element used = in place of "supplementary information" = (<relatedTo>)

We have not = added yet "view", "role" and "presentation". We have left "content" to = describe the content of a capture.
It seems to us that no final consensus has been reached = about all of them, since mail threads have been left = pending.
Nonetheless, we = believe the definition of keywords can help the capture selection = process on the consumer side, but further discussion is needed to define = them.

We have moved = out from the <captureScene> blob the description of the available = media captures again.
Indeed, = media captures should have identifiers that are valid out of the local = scope of capture scenes, since a consumer should be able to request also = single captures in the CONFIGURE message. In each media capture, a = reference to the capture scene containing it is provided. It identifies = the space the spatial information of the media capture refers = to.

Comments are welcome.
Cheers,

Roberta & = Simon


_______________________________________________
clue mailing = list
clue@ietf.org
https://www.ietf.org/m= ailman/listinfo/clue


_______________________________________= ________
clue mailing list
clue@ietf.org
https://www.ietf.org/ma= ilman/listinfo/clue


      =                 =    =     _\\|//_
          =                   =       ( 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=_674C3591-6CF7-4766-9182-6F9BA12684D3-- From roberta.presta@unina.it Thu Feb 28 04:04: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 58DA521F8ADC for ; Thu, 28 Feb 2013 04:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.116 X-Spam-Level: X-Spam-Status: No, score=-0.116 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 4a1V07nzXEA6 for ; Thu, 28 Feb 2013 04:04:44 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3497F21F8ABC for ; Thu, 28 Feb 2013 04:04:44 -0800 (PST) Received: from [127.0.0.1] ([143.225.229.193]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r1SC4fUP027617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 13:04:42 +0100 Message-ID: <512F47E1.9090600@unina.it> Date: Thu, 28 Feb 2013 13:04:49 +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: Christian Groves , clue@ietf.org References: <512E54AD.9090707@unina.it> <512ED663.80103@nteczone.com> In-Reply-To: <512ED663.80103@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130228-0, 28/02/2013), Outbound message X-Antivirus-Status: Clean 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, 28 Feb 2013 12:04:45 -0000 Hi Christian, I reply below. Il 28/02/2013 05:00, Christian Groves ha scritto: > >> 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. > [CNG] I agree that there could be several difference reasons why the > Advertiser might indicate that there is a simultaneity limitations. It > could also relate to scene composition issues, i.e. if a movable > device is capturing different regions in the advertised captures. > Think would a device physical constraint rather than a transmission > physical constraint. I think the main thing is that the reason to send > a simultaneity constraint is not limited. > >> >> 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. > [CNG] Do we need the text "(though it may not make sense to do so)"? > If the consumer chooses a "strange" set of captures then it should > make sense to it. It may not make sense to an Advertiser. Also do we > need "physically", i.e. is it sufficient to say "...that could be > transmitted at the same time." > [RP] +1 >> >> 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?) > [CNG] I'm not sure what you mean by "in almost one of the listed ones." [RP] Let's suppose there are two advertised simultaneous sets: 1) VC1, VC2, VC5 2) VC1, VC2, VC6 The consumer must verify that the list of captures he desires is fully included at least or in set (1) or in set (2). For example, if the consumer's desired list of captures is, for example, (VC1, VC2), or (VC1, VC2, VC5), then the check is verified. If the consumer's desired list of captures is (VC1, VC2, VC5, VC6) the check is not verified. I'm just applying what is actually stated in the framework up to now. > I think the intention is that the selected captures firstly meet a > "capture scene entry" and then the "simultaneous set" if they don't. [RP] What I have understood by reading the framework document is slightly different. Capture scene entries are defined as set of captures that can be sent simultaneously, so there is no doubt about it. Nonetheless, if simultaneity constraints are present in an advertisement, the consumer must verify that his capture selection fits such constraints. If simultaneity constraints are *present*, the only case in which they can be skipped is the one where the consumer chooses only one capture scene entry (i.e., a set of captures listed in the same capture scene entry), or captures belonging to the same capture scene entry. If the consumer selects more than one capture scene entry, and simultaneity constraints are present, they should be checked. Indeed, captures belonging to different scene entries could not be able to be sent simultaneously. > If the consumer can't get a match then I guess there would be a > failure. Maybe we need an additional error in Paul K's signalling > document for a Configure message? i.e. "Unable to select captures due > to local constraints" > >> >> 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. > [CNG] My understanding is that a CSE is under a capture scene? I'm not > sure how the above examples relate to that. > [RP] I try to explain what I have in mind by providing a couple of examples. Suppose we have three capture scenes: 1) CSA made by three scene entries: CSE1_A, CSE2_A, CSE3_A 2) CSB made by three scene entries: CSE1_B, CSE2_B, CSE3_B 3) CSC made by three scene entries: CSE1_C, CSE2_C, CSE3_C Suppose that each capture scene entry is made of three captures ==> we have 27 captures. Suppose that I want to offer OR (CSA and CSB) OR (CSA and CSC). I can provide two simultaneous sets: - CSA, CSB - CSA, CSC without listing all the captures for each alternative. Let's make another example. Suppose that CSE1_A and CSE2_A are not compatible because of physical constraints. If I want to express just such a limitation, by applying the philosophy of the current framework document, I should list two sets: - all captures in CSB, all captures in CSC, all captures in CSE3_A, and all captures in CSE1_A - all captures in CSB, all captures in CSC, all captures in CSE3_A, and all captures in CSE2_A 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 >> >> >> 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. > [CNG] There's probably a thesis for someone to study whether inclusion > or exclusion is best. I guess the tradeoff of less signalling data is > possibly more processing to determine whether the Consumers choice fits. >> >> 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)." > [CNG] I'm for keeping things simple and assuming "or". If we define > robust version/extension mechanisms if we find its a issue we could > enhance CLUE by having more extension syntax. >> >> Do you think we should stuck on the framework solution or also >> consider the aforementioned alternatives? >> I promise I stop thinking about it! > [CNG] Don't stop thinking about it. It's good that its being > questioned, that leads to a better protocol. >> >> RP >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > -- 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 From christer.holmberg@ericsson.com Thu Feb 28 04:24: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 18CFA21F84A9 for ; Thu, 28 Feb 2013 04:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, 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 924j4h3Ovkfr for ; Thu, 28 Feb 2013 04:24:09 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4FB21F84AF for ; Thu, 28 Feb 2013 04:24:08 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-d6-512f4c67c5fe Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6D.3B.10459.76C4F215; Thu, 28 Feb 2013 13:24:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 13:24:07 +0100 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: Christer's initial comments on framework-09 Thread-Index: Ac4VroADjRD7KAXuTk65+jHWtYvPhA== Date: Thu, 28 Feb 2013 12:24:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B10BE90@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_7594FB04B1934943A5C02806D1A2204B10BE90ESESSMB209ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUyM+JvjW66j36gQf8tGYv9py4zOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/fnlawFz9Qr/u3ZwdjAeE6pi5GDQ0LAROLMraQuRk4gU0zi wr31bF2MXBxCAocYJV5u2c0E4SxmlLh+qosVpIFNwEKi+582SIOIgLLE0c39bCC2MNCchf1z WSHilhI3vuxigrD1JK6cmccIYrMIqEqsnz8NrJ5XwFtix8ypYDWMQIu/n1oDZjMLiEvcejKf CeIgAYkle84zQ9iiEi8f/2OFsBUlrk5fDlWfL3Hk+EyomYISJ2c+YZnAKDQLyahZSMpmISmD iOtILNj9iQ3C1pZYtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLDTcxAoP+4JbfujsYT50TOcQo zcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOj/6y/1uzHw/w23ubNtV9+2e5X +rWUI5vu/TD2vcJhLbIkfc/yM+xbjvaw2mo/t+l6LTF9rvf0ie0uqp8z72iu2fnCqmav9ME7 1bP32t3+LJXWdnLfxt9rUr7PsOA5blJ0nEG+6OzLPa/O/bnqJfg+LrvHgX2HesRWCZ4zq1tF DhtGnGdt3dH8SYmlOCPRUIu5qDgRANpovU5IAgAA Subject: [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: Thu, 28 Feb 2013 12:24:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B10BE90ESESSMB209ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 c= onclusion. 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 provid= e all captures within a given CSE. So, there is no need to explicitly adver= tise that the captures associated with a given CSE can be provided simultan= eously. ------------------- Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B10BE90ESESSMB209ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

A couple of initial comments:

 

-------------------

 

Q1: Capture Scene and Capture Scene Entry editorial<= o:p>

 

In a few places, there is text saying that ”a = Capture Scene includes one or more Capture Scene Entries”. I think th= at 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, a= nd 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 t= o simultaneously provide all captures within a given CSE. So, there is no n= eed to explicitly advertise that the captures associated with a given CSE c= an be provided simultaneously.

 

-------------------

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B10BE90ESESSMB209ericsso_-- From roberta.presta@unina.it Thu Feb 28 06:19: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 7161A21F88DD for ; Thu, 28 Feb 2013 06:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.317 X-Spam-Level: X-Spam-Status: No, score=-0.317 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Pi0vQv-h4PvW for ; Thu, 28 Feb 2013 06:19:06 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 725EC21F8B75 for ; Thu, 28 Feb 2013 06:19:06 -0800 (PST) Received: from [127.0.0.1] ([143.225.229.193]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r1SEJ2MD010319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 15:19:03 +0100 Message-ID: <512F675D.4020102@unina.it> Date: Thu, 28 Feb 2013 15:19:09 +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 , clue@ietf.org References: <512E532B.7000107@unina.it> <512E8805.1020409@alum.mit.edu> In-Reply-To: <512E8805.1020409@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130228-0, 28/02/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] data model - ongoing work X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Feb 2013 14:19:07 -0000 Hi Paul, Il 27/02/2013 23:26, Paul Kyzivat ha scritto: > >> >> With this idea in mind, we are currently defining a >> element representing the concept of capture encoding as defined in the >> framework. It contains a reference to a media capture and one ore more >> individual encodings, each one characterized by the consumer's desired >> parameters (as envisioned in par 9 page 32 of the framework-09 version). > > Why would a single capture-encoding reference more than one encoding? > If that is for multicast, then I would expect each encoding to result > in a separate capture-encoding. Yes, you are right. Conceptually, a capture encoding is given from the association of a media capture with an encoding configured with a given set of parameters. For example, a video capture encoded with H263 with a certain frame rate. I got misled when thinking about the consumer's configuration options stated in par. 9. Thanks, RP From Christian.Groves@nteczone.com Thu Feb 28 15:03:37 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 9ABFE21F89D3 for ; Thu, 28 Feb 2013 15:03:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckxEor085bpy for ; Thu, 28 Feb 2013 15:03:36 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 657A621F8A09 for ; Thu, 28 Feb 2013 15:03:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAL3hL1F20U5n/2dsb2JhbAANOMIzgRSDEgEBAQQBAQEvAQUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiBuuNZMjBI8bFoMqA5MAl0c Received: from ppp118-209-78-103.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.78.103]) by ipmail06.adl6.internode.on.net with ESMTP; 01 Mar 2013 09:33:20 +1030 Message-ID: <512FE233.8010104@nteczone.com> Date: Fri, 01 Mar 2013 10:03:15 +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: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B10BE90@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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: Thu, 28 Feb 2013 23:03:37 -0000 Hello Christer, For Q1 I think the definition of CSE indicates that its an entire scene. 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. Regards, Christian 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 From Christian.Groves@nteczone.com Thu Feb 28 15:17: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 556EC21F8AE3 for ; Thu, 28 Feb 2013 15:17:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smRxpkqPssyH for ; Thu, 28 Feb 2013 15:17:17 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 1604321F8A85 for ; Thu, 28 Feb 2013 15:17:16 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAA7kL1F20U5n/2dsb2JhbAANOMIzgRSDEgEBAQMBOBslARALIRYPCQMCAQIBRQYNAQcBAYgJrk+TJI8UB4NAA6pH Received: from ppp118-209-78-103.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.78.103]) by ipmail06.adl6.internode.on.net with ESMTP; 01 Mar 2013 09:47:09 +1030 Message-ID: <512FE570.4090006@nteczone.com> Date: Fri, 01 Mar 2013 10:17:04 +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: Roberta Presta 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 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, 28 Feb 2013 23:17:18 -0000 Hello Roberta, Please see below. Regards, Christian ..snip >>> 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?) >> [CNG] I'm not sure what you mean by "in almost one of the listed ones." > [RP] > Let's suppose there are two advertised simultaneous sets: > 1) VC1, VC2, VC5 > 2) VC1, VC2, VC6 > The consumer must verify that the list of captures he desires is fully > included at least or in set (1) or in set (2). > For example, if the consumer's desired list of captures is, for > example, (VC1, VC2), or (VC1, VC2, VC5), then the check is verified. > If the consumer's desired list of captures is (VC1, VC2, VC5, VC6) the > check is not verified. > I'm just applying what is actually stated in the framework up to now. [CNG] OK that's my understanding also. > >> I think the intention is that the selected captures firstly meet a >> "capture scene entry" and then the "simultaneous set" if they don't. > > [RP] What I have understood by reading the framework document is > slightly different. > Capture scene entries are defined as set of captures that can be sent > simultaneously, so there is no doubt about it. > Nonetheless, if simultaneity constraints are present in an > advertisement, the consumer must verify that his capture selection > fits such constraints. > If simultaneity constraints are *present*, the only case in which they > can be skipped is the one where the consumer chooses only one capture > scene entry (i.e., a set of captures listed in the same capture scene > entry), or captures belonging to the same capture scene entry. > If the consumer selects more than one capture scene entry, and > simultaneity constraints are present, they should be checked. Indeed, > captures belonging to different scene entries could not be able to be > sent simultaneously. [CNG] I think we have the same understanding. > >> If the consumer can't get a match then I guess there would be a >> failure. Maybe we need an additional error in Paul K's signalling >> document for a Configure message? i.e. "Unable to select captures due >> to local constraints" >> >>> >>> 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. >> [CNG] My understanding is that a CSE is under a capture scene? I'm >> not sure how the above examples relate to that. >> > [RP] I try to explain what I have in mind by providing a couple of > examples. > > Suppose we have three capture scenes: > 1) CSA made by three scene entries: CSE1_A, CSE2_A, CSE3_A > 2) CSB made by three scene entries: CSE1_B, CSE2_B, CSE3_B > 3) CSC made by three scene entries: CSE1_C, CSE2_C, CSE3_C > Suppose that each capture scene entry is made of three captures ==> we > have 27 captures. > > Suppose that I want to offer OR (CSA and CSB) OR (CSA and CSC). I can > provide two simultaneous sets: > - CSA, CSB > - CSA, CSC > without listing all the captures for each alternative. [CNG] OK > > Let's make another example. Suppose that CSE1_A and CSE2_A are not > compatible because of physical constraints. > If I want to express just such a limitation, by applying the > philosophy of the current framework document, I should list two sets: > - all captures in CSB, all captures in CSC, all captures in CSE3_A, > and all captures in CSE1_A > - all captures in CSB, all captures in CSC, all captures in CSE3_A, > and all captures in CSE2_A > 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 [CNG] OK. Sounds reasonable. Are you proposing to still keep individual captures in the STS? i.e. VC1, VC2. If so we may have to scope these to a CSE/CS because you can use the same captureID in different CSEs. It may get confusing it we don't? ..snip