From pkyzivat@cisco.com Sat Jul 2 07:36:52 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D82211E811F for ; Sat, 2 Jul 2011 07:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 2wX9Cp+TZM8Y for ; Sat, 2 Jul 2011 07:36:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 40E8911E80DD for ; Sat, 2 Jul 2011 07:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1338; q=dns/txt; s=iport; t=1309617411; x=1310827011; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lwiqHPvScAcY9sj8EwBDHnhQwW1CovY1GyvEOD7JUfY=; b=JGVNK4VU7pddq//ZnjcMkdshThie46pisSV/sQpuTQLTVVXqs71u4/A0 Eevc2KBoKUuD7g8/M5NlxG3UiDi/fpljMNseFy2LIetpq6LFDanQp96bF fvWxJsv3KK+J8IvGu2zgxsxjmqRbmvIO3X9S5u2il29qxSqmKJM5ZL1zD k=; X-IronPort-AV: E=Sophos;i="4.65,463,1304294400"; d="scan'208";a="725845002" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2011 14:36:50 +0000 Received: from [10.86.248.126] (bxb-vpn3-126.cisco.com [10.86.248.126]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p62Eanrw021692; Sat, 2 Jul 2011 14:36:49 GMT Message-ID: <4E0F2D00.6090801@cisco.com> Date: Sat, 02 Jul 2011 10:36:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "Duckworth, Mark" References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04D457B2@xmb-sjc-221.amer.cisco.com> <44C6B6B2D0CF424AA90B6055548D7A61AC7E4105@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AC7E4105@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: CLUE Subject: Re: [clue] definitions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:36:52 -0000 I'm not aware of any procedure having been adopted for managing definitions. As long as all the documents are individual drafts, it is really up to the authors to sort it out among themselves. Once one or more become wg drafts, we need to be more formal. Since the requirements doc is the first one to become a wg draft, it should, for now, be definitive for the definitions it contains. If you have to coin some new definitions while producing the first wg draft, then I guess you just do it, and they can be collected in the definitions doc. As other docs become wg drafts this will get more complex. Regardless, I would like to see more list discussion about this stuff. (I'm including the list in this reply.) Thanks, Paul On 7/1/2011 10:47 PM, Duckworth, Mark wrote: > Sorry, I don’t know what our procedure is for that. > > *From:*Allyn Romanow (allyn) [mailto:allyn@cisco.com] > *Sent:* Friday, July 01, 2011 10:40 PM > *To:* Duckworth, Mark > *Cc:* Paul Kyzivat (pkyzivat); Mary Barnes > *Subject:* definitions > > Hey.. > > Do you know the protocol for definitions?.. when we put new definitions > in our doc, do we send a note to Stephan to have them put in his doc. > And he brings them up for discussion before putting them in.. or exactly > what is the process? > > thanks > From stewe@stewe.org Sat Jul 2 09:01:04 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8FE22800F for ; Sat, 2 Jul 2011 09:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.699, 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 jgTgIOSFdegv for ; Sat, 2 Jul 2011 09:01:03 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id B7A5221F8639 for ; Sat, 2 Jul 2011 09:01:02 -0700 (PDT) Received: from [192.168.1.107] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 8640-1743317 for multiple; Sat, 02 Jul 2011 18:01:00 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Sat, 02 Jul 2011 09:00:40 -0700 From: Stephan Wenger To: Paul Kyzivat , "Duckworth, Mark" Message-ID: Thread-Topic: [clue] definitions In-Reply-To: <4E0F2D00.6090801@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Cc: CLUE Subject: Re: [clue] definitions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 16:01:04 -0000 I plan to rev the definition draft shortly to reflect WG drafts and the outcome of the mailing list discussions. I don't think we need any formal procedure for this draft (or any other draft not intended for publication). The draft was meant as a tool to help making other drafts consistent. We are IMO almost at this stage, and I would not be surprised if the forthcoming version of definitions would be the last one... Stephan On 7.2.2011 07:36 , "Paul Kyzivat" wrote: >I'm not aware of any procedure having been adopted for managing >definitions. As long as all the documents are individual drafts, it is >really up to the authors to sort it out among themselves. >Once one or more become wg drafts, we need to be more formal. > >Since the requirements doc is the first one to become a wg draft, it >should, for now, be definitive for the definitions it contains. If you >have to coin some new definitions while producing the first wg draft, >then I guess you just do it, and they can be collected in the >definitions doc. > >As other docs become wg drafts this will get more complex. > >Regardless, I would like to see more list discussion about this stuff. >(I'm including the list in this reply.) > > Thanks, > Paul > >On 7/1/2011 10:47 PM, Duckworth, Mark wrote: >> Sorry, I don=B9t know what our procedure is for that. >> >> *From:*Allyn Romanow (allyn) [mailto:allyn@cisco.com] >> *Sent:* Friday, July 01, 2011 10:40 PM >> *To:* Duckworth, Mark >> *Cc:* Paul Kyzivat (pkyzivat); Mary Barnes >> *Subject:* definitions >> >> Hey.. >> >> Do you know the protocol for definitions?.. when we put new definitions >> in our doc, do we send a note to Stephan to have them put in his doc. >> And he brings them up for discussion before putting them in.. or exactly >> what is the process? >> >> thanks >> >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Sun Jul 3 14:31:47 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0802B21F85D0 for ; Sun, 3 Jul 2011 14:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 69U3VleV2JH8 for ; Sun, 3 Jul 2011 14:31:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by ietfa.amsl.com (Postfix) with ESMTP id DD7DA21F85DC for ; Sun, 3 Jul 2011 14:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1508; q=dns/txt; s=iport; t=1309728705; x=1310938305; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=J29LNPzUH+LWQl5GBcyqnTe4eYuVSmnrCr7uRJFD54w=; b=jprKbT6z/QdKJiWTELd3JPXnIjpntQJ0Cppp9AUJbkU7WukdM35NjPkc Nu5kytJbumpnOe0wfXzDMSJzrSNdWfrtU3jLSLiGmRmgq0UJ7LD0oLAY1 KIJmeCMpyi4QkddifGWR4p7L9WAGPrluFY0BkRXsDk7ramdN+jP8c6q4z o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkBALzeEE6rRDoG/2dsb2JhbABShEKUBkKNfHZ3rBWBIo0Xj2qBK4N/gQwEhz+PeItV X-IronPort-AV: E=Sophos;i="4.65,468,1304294400"; d="scan'208";a="360194424" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-5.cisco.com with ESMTP; 03 Jul 2011 21:31:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p63LVjSH025376 for ; Sun, 3 Jul 2011 21:31:45 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jul 2011 14:31:45 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 3 Jul 2011 14:31:40 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04D45819@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-romanow-clue-framework-00.txt Thread-Index: Acw5yGOQjEx2NapwSjuqXrun//JqxgAAArYA From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 03 Jul 2011 21:31:45.0237 (UTC) FILETIME=[9B85A050:01CC39C8] Subject: [clue] FW: New Version Notification for draft-romanow-clue-framework-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, 03 Jul 2011 21:31:47 -0000 Rm9sa3MsDQoNCkEgZmlyc3QgZHJhZnQgZm9yIHRoZSBmcmFtZXdvcmsgaGFzIGp1c3QgYmVlbiBw b3N0ZWQuDQoNCkJlc3QgcmVnYXJkcywNCkFsbHluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBKdWx5IDAzLCAyMDExIDI6MzAgUE0NClRvOiBB bGx5biBSb21hbm93IChhbGx5bikNCkNjOiBtYXJrLmR1Y2t3b3J0aEBwb2x5Y29tLmNvbTsgQWxs eW4gUm9tYW5vdyAoYWxseW4pOyBBbmRyZXcgUGVwcGVyZWxsIChhcGVwcGVyZSk7IG1hcmsuZ29y enluc2tpQGhwLmNvbTsgYmJhbGRpbm9AcG9seWNvbS5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcm9tYW5vdy1jbHVlLWZyYW1ld29yay0wMC50eHQNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJvbWFub3ctY2x1ZS1mcmFtZXdvcmstMDAudHh0 IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQWxseW4gUm9tYW5vdyBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtcm9tYW5vdy1j bHVlLWZyYW1ld29yaw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgRnJhbWV3b3JrIGZvciBUZWxl cHJlc2VuY2UgTXVsdGktU3RyZWFtcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTEtMDctMDMNCldHIElE OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAzMQ0KDQpBYnN0cmFj dDoNCiAgIFRoaXMgbWVtbyBvZmZlcnMgYSBmcmFtZXdvcmsgZm9yIGEgcHJvdG9jb2wgdGhhdCBl bmFibGVzIGRldmljZXMgaW4gYQ0KICAgdGVsZXByZXNlbmNlIGNvbmZlcmVuY2UgdG8gaW50ZXJv cGVyYXRlIGJ5IHNwZWNpZjt5aW5nIHRoZQ0KICAgcmVsYXRpb25zaGlwcyBiZXR3ZWVuIG11bHRp cGxlIFJUUCBzdHJlYW1zLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg== From internet-drafts@ietf.org Sat Jul 9 04:04:05 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2321F8607; Sat, 9 Jul 2011 04:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=0.560, 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 mtqiRKDcz4ly; Sat, 9 Jul 2011 04:04:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08B21F85FD; Sat, 9 Jul 2011 04:04:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110709110405.18137.65372.idtracker@ietfa.amsl.com> Date: Sat, 09 Jul 2011 04:04:05 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-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: Sat, 09 Jul 2011 11:04:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEle= presence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Iformata Communications Filename : draft-ietf-clue-telepresence-use-cases-01.txt Pages : 16 Date : 2011-07-09 Telepresence conferencing systems seek to create the sense of really being present. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-clue-telepresence-use-cases-= 01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-clue-telepresence-use-cases-0= 1.txt From Even.roni@huawei.com Sat Jul 9 04:47:38 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25ABF21F8770 for ; Sat, 9 Jul 2011 04:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 NyeP1EZwvC19 for ; Sat, 9 Jul 2011 04:47:37 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 13ECC21F85B1 for ; Sat, 9 Jul 2011 04:47:37 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO2003SIE398Q@szxga05-in.huawei.com> for clue@ietf.org; Sat, 09 Jul 2011 19:47:33 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO200BC3E38FP@szxga05-in.huawei.com> for clue@ietf.org; Sat, 09 Jul 2011 19:47:33 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO200DRBE30IQ@szxml11-in.huawei.com> for clue@ietf.org; Sat, 09 Jul 2011 19:47:32 +0800 (CST) Date: Sat, 09 Jul 2011 14:44:56 +0300 From: Roni Even To: clue@ietf.org Message-id: <00d001cc3e2d$a61d24c0$f2576e40$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=UTF-8 Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acw+J+26AxUzwFe0SMSAfcCOL9VwkQABZXEA Subject: [clue] FW: New Version Notification for draft-ietf-clue-telepresence-use-cases-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: Sat, 09 Jul 2011 11:47:38 -0000 Hi, I submitted a new revision that includes the multiview multipoint use case Roni -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Saturday, July 09, 2011 2:04 PM To: Even.roni@huawei.com Cc: marshall.eubanks@ilformata.com; mark.duckworth@polycom.com; allyn@cisco.com; stephen.botzko@polycom.com; Even.roni@huawei.com Subject: New Version Notification for draft-ietf-clue-telepresence-use-cases-01.txt A new version of I-D, draft-ietf-clue-telepresence-use-cases-01.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-ietf-clue-telepresence-use-cases Revision: 01 Title: Use Cases for Telepresence Multi-streams Creation date: 2011-07-09 WG ID: clue Number of pages: 16 Abstract: Telepresence conferencing systems seek to create the sense of really being present. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The IETF Secretariat From Even.roni@huawei.com Sun Jul 10 14:27:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8304621F87C2 for ; Sun, 10 Jul 2011 14:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 IlEYczO+PGbr for ; Sun, 10 Jul 2011 14:27:53 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id D27A821F8797 for ; Sun, 10 Jul 2011 14:27:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO4009YTZMEUQ@szxga03-in.huawei.com> for clue@ietf.org; Mon, 11 Jul 2011 05:27:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LO400IIYZME5Q@szxga03-in.huawei.com> for clue@ietf.org; Mon, 11 Jul 2011 05:27:50 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-32-59.red.bezeqint.net [79.179.32.59]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LO4009Q6ZM4ZQ@szxml12-in.huawei.com> for clue@ietf.org; Mon, 11 Jul 2011 05:27:50 +0800 (CST) Date: Mon, 11 Jul 2011 00:25:09 +0300 From: Roni Even To: clue@ietf.org Message-id: <005301cc3f47$df3b5fe0$9db21fa0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acw6niPdHWobMNCZTbCKE6pftHYosAEqWfvw Subject: [clue] FW: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-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, 10 Jul 2011 21:27:53 -0000 Hi, You may find this draft interesting since it tries to discuss how to signal multistreams using payload type SSRC multiplexing and RTP session multiplexing. It also discuss payload type multiplexing Roni Even -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, July 05, 2011 2:00 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-westerlund-avtcore-multistream-and-simulcast-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Multiple Stream Sessions and Simulcast Author(s) : Magnus Westerlund Bo Burman Filename : draft-westerlund-avtcore-multistream-and-simulcast-00.txt Pages : 60 Date : 2011-07-04 RTP has always been a protocol that supports multiple participants each sending their own media streams in an RTP session. Unfortunately many implementations aimed only at point to point voice over IP with a single source in each end-point. Even client implementations aimed at video conferences have often been built with the assumption around central mixers that only deliver a single media stream per media type. Thus any application that wants to allow for more advance usage where multiple media streams are sent and received by an end-point has a problem with legacy. This issue is analyzed, and RTP clarifications and signalling extensions are proposed to handle this issue. A related issue is how to perform simulcast, in the meaning of sending multiple encodings or representations of the same media source, when using RTP for media transport. This is further analyzed and possible solutions discussed and we arrive at a conclusion for session multiplexing of simulcast versions. We also found a number of related issues when having multiple streams and simulcast. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-westerlund-avtcore-multistream-and -simulcast-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-westerlund-avtcore-multistream-and- simulcast-00.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From pkyzivat@alum.mit.edu Mon Jul 11 10:42:52 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E4F21F8784 for ; Mon, 11 Jul 2011 10:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 iXCVelwgvUWH for ; Mon, 11 Jul 2011 10:42:52 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8581721F877D for ; Mon, 11 Jul 2011 10:42:52 -0700 (PDT) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta04.emeryville.ca.mail.comcast.net with comcast id 6efZ1h0021eYJf8A4hipMj; Mon, 11 Jul 2011 17:42:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.emeryville.ca.mail.comcast.net with comcast id 6hiv1h01B0tdiYw01hiwLE; Mon, 11 Jul 2011 17:42:57 +0000 Message-ID: <4E1B361A.8070607@alum.mit.edu> Date: Mon, 11 Jul 2011 13:42:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Change of affiliation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 17:42:52 -0000 For anyone who cares, I accepted an opportunity to leave Cisco on favorable terms, and am now a free agent. I intend to continue my full participation in IETF while I decide what to do next. I expect that I will continue to be involved in the field one way or another. I'll be seeing you all in Quebec City. Thanks, Paul From stewe@stewe.org Mon Jul 11 15:36:19 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7588E11E8359 for ; Mon, 11 Jul 2011 15:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 pVUFswROBzMh for ; Mon, 11 Jul 2011 15:36:18 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id C174111E8355 for ; Mon, 11 Jul 2011 15:36:15 -0700 (PDT) Received: from [192.168.1.104] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 11855-1743317 for ; Tue, 12 Jul 2011 00:36:14 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Mon, 11 Jul 2011 15:36:05 -0700 From: Stephan Wenger To: CLUE Message-ID: Thread-Topic: definition-01 posted Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393243373_6587645" X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: [clue] definition-01 posted X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:36:19 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393243373_6587645 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi all, I just posted draft-wenger-clue-definitions-01, in an attempt to reflect the outcome of the mailing list discussions of the last few months. I'm sure I missed a number of points. Below are those I didn't miss (from the change log). Stephan 01: removed "stage direction" in "left" "right". Replaced with "to be interpreted in context". clarified "local" to mean "in the same room" per J. Polk email 6/14/11 Consistently refer to "loudspeaker" per Christer's email 6/13/11 Added "keyboard" to listed caputure devices per Christer's email 6/13/11 Rendering device: changed "optical" to "visual". Hope Christer finds this OK. Per Christer's email 6/13/11 Note: the other changes proposed by Christer in his 6/13 email appear to change more than just words but semantics. Not included here as such semantic changes are best handled in the requirement and other docs. Edt. Note: there have been lengthily discussions about the term "Participant". One camp wanted the word to refer to human users of telepresence equipment so to use intuitive language, the other (as this document) suggests to use the word in the RFC Participant defined as per RFC 4353. I think this is what we arrived at on the mailing list, right? Added "Telepresence Extensions" per long "solutions" thread. --B_3393243373_6587645 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi all,
I just pos= ted draft-wenger-clue-definitions-01, in an attempt to reflect the outcome o= f the mailing list discussions of the last few months.  I'm sure I miss= ed a number of points.  Below are those I didn't miss (from the change = log).
Stephan


 &= nbsp; 01: 

   removed "stage directi= on" in "left" "right".  Replaced with "to
   be int= erpreted in context".

   clarified "local= " to mean "in the same room" per J. Polk email
   6/14/1= 1

   Consistently refer to "loudspeaker" = per Christer's email 6/13/11

   Added "ke= yboard" to listed caputure devices per Christer's email
 &nbs= p; 6/13/11

   Rendering device: changed "= optical" to "visual".  Hope Christer finds
   this = OK.  Per Christer's email 6/13/11

  = Note: the other changes proposed by Christer in his 6/13 email appear
=
   to change more than just words but semantics.  Not in= cluded here as
   such semantic changes are best handled= in the requirement and other
   docs.

   Edt. Note: there have been lengthily discussions about = the term
   "Participant".  One camp wanted the wor= d to refer to human users of
   telepresence equipment s= o to use intuitive language, the other (as
   this docum= ent) suggests to use the word in the RFC

 &nbs= p; Participant defined as per RFC 4353.  I think this is what we arrive= d
   at on the mailing list, right?

=
   Added "Telepresence Extensions" per long "solutions" threa= d.
--B_3393243373_6587645-- From stephen.botzko@gmail.com Mon Jul 11 15:43:00 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8BDF11E8084 for ; Mon, 11 Jul 2011 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEIyVi7j9ItP for ; Mon, 11 Jul 2011 15:43:00 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 448FB21F8E2F for ; Mon, 11 Jul 2011 15:42:59 -0700 (PDT) Received: by vws12 with SMTP id 12so4554708vws.31 for ; Mon, 11 Jul 2011 15:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WAVXTSnUCQdEDS/kDz89m6B2bx2eO234u30PQ6QGu3w=; b=HCnYOBLm2Pho2sxFCiS3E1bCPdwB7mKdIlk6QWeKiuoAU0eh+QMNIqqiruaXN2DIPd yqjNtMyNceb8QltqRcY5kCbRJnpmU/VL1cXaY2IJfeZFn+jKSeh+MqkFXyuHmWTKMb3g KhNuHFqfnNq4RvxidZjJ5to4SmbvE/hhcDntk= MIME-Version: 1.0 Received: by 10.52.180.8 with SMTP id dk8mr2822301vdc.377.1310424178488; Mon, 11 Jul 2011 15:42:58 -0700 (PDT) Received: by 10.52.116.34 with HTTP; Mon, 11 Jul 2011 15:42:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Jul 2011 18:42:58 -0400 Message-ID: From: Stephen Botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=bcaec51964f1a9f6ec04a7d2e76e Cc: CLUE Subject: Re: [clue] definition-01 posted X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 22:43:00 -0000 --bcaec51964f1a9f6ec04a7d2e76e Content-Type: text/plain; charset=ISO-8859-1 inline On Mon, Jul 11, 2011 at 6:36 PM, Stephan Wenger wrote: > Hi all, > I just posted draft-wenger-clue-definitions-01, in an attempt to reflect > the outcome of the mailing list discussions of the last few months. I'm > sure I missed a number of points. Below are those I didn't miss (from the > change log). > Stephan > > > 01: > > removed "stage direction" in "left" "right". Replaced with "to > be interpreted in context". > > clarified "local" to mean "in the same room" per J. Polk email > 6/14/11 > > Consistently refer to "loudspeaker" per Christer's email 6/13/11 > > Added "keyboard" to listed caputure devices per Christer's email > 6/13/11 > > Rendering device: changed "optical" to "visual". Hope Christer finds > this OK. Per Christer's email 6/13/11 > > Note: the other changes proposed by Christer in his 6/13 email appear > to change more than just words but semantics. Not included here as > such semantic changes are best handled in the requirement and other > docs. > > Edt. Note: there have been lengthily discussions about the term > "Participant". One camp wanted the word to refer to human users of > telepresence equipment so to use intuitive language, the other (as > this document) suggests to use the word in the RFC > > Participant defined as per RFC 4353. I think this is what we arrived > at on the mailing list, right? > That is my interpretation of the outcome on the list (as someone who is in the "human users" camp). In the end I think we settled on the 4353 definition in order to be consistent with normal IETF usage. Stephen Botzko > > Added "Telepresence Extensions" per long "solutions" thread. > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --bcaec51964f1a9f6ec04a7d2e76e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline

On Mon, Jul 11, 2011 at 6:36 PM, S= tephan Wenger <stew= e@stewe.org> wrote:
Hi all,
I just posted draft-wenge= r-clue-definitions-01, in an attempt to reflect the outcome of the mailing = list discussions of the last few months. =A0I'm sure I missed a number = of points. =A0Below are those I didn't miss (from the change log).
Stephan


=A0=A0 01:=A0

=A0=A0 removed "stage direction" in "l= eft" "right". =A0Replaced with "to
=A0=A0 be = interpreted in context".

=A0=A0 clarified "local" to mean "in the= same room" per J. Polk email
=A0=A0 6/14/11

<= /div>
=A0=A0 Consistently refer to "loudspeaker" per Christer= 's email 6/13/11

=A0=A0 Added "keyboard" to listed caputure de= vices per Christer's email
=A0=A0 6/13/11

=A0=A0 Rendering device: changed "optical" to "visual&= quot;. =A0Hope Christer finds
=A0=A0 this OK. =A0Per Christer's email 6/13/11

=A0=A0 Note: the other changes proposed by Christer in his 6/13 emai= l appear
=A0=A0 to change more than just words but semantics. =A0= Not included here as
=A0=A0 such semantic changes are best handled in the requirement and o= ther
=A0=A0 docs.

=A0=A0 Edt. Note: ther= e have been lengthily discussions about the term
=A0=A0 "Par= ticipant". =A0One camp wanted the word to refer to human users of
=A0=A0 telepresence equipment so to use intuitive language, the other = (as
=A0=A0 this document) suggests to use the word in the RFC

=A0=A0 Participant defined as per RFC 4353. =A0I thin= k this is what we arrived
=A0=A0 at on the mailing list, right?
=A0
That is my interpretation of the outcome on the list (as s= omeone who is in the "human users" camp).=A0 In the end I think w= e settled on the 4353 definition in order to be consistent with normal IETF= usage.

Stephen Botzko

=A0=A0 Added "Telepresence Extensions" p= er long "solutions" thread.

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


--bcaec51964f1a9f6ec04a7d2e76e-- From Christian.Groves@nteczone.com Mon Jul 11 20:41:17 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B8711E841D for ; Mon, 11 Jul 2011 20:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 rhWF3A9qR4vm for ; Mon, 11 Jul 2011 20:41:16 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by ietfa.amsl.com (Postfix) with ESMTP id DA19C11E8410 for ; Mon, 11 Jul 2011 20:41:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0CAPLBG0520crk/2dsb2JhbAAMR5gx2iKGOgSjNw Received: from ppp118-209-202-228.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.202.228]) by ipmail05.adl6.internode.on.net with ESMTP; 12 Jul 2011 13:11:05 +0930 Message-ID: <4E1BC24C.2010705@nteczone.com> Date: Tue, 12 Jul 2011 13:41:00 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] definition-01 posted X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 03:41:17 -0000 Hello Stephan, I think you may have given me a name change, I think you are referring to my (Christian's) email rather than "Christer's". A few comments: ------------------------- My previous comment was: Remote: "A remote can be an Endpoint or an MCU". I don't think "remote" is being proposed to be a noun by the definition. Perhaps "A remote can be...."? This wasn't picked up and I don't think its about changing semantics, its editorial as it doesn't read right. Some different options: a) Remote can be used to describe an Endpoint or MCU. b) A Remote entity can be an Endpoint or an MCU. c) Delete "A remote can be an Endpoint or MCU". This sentence isn't used for the local definition, so its questionable why its in the remote definition. Also my previous comment regarding the definition of Audio mixing I don't think falls into the "semantic/requirements" realm. The definition of "Audio Mixing" says "... See RTP Topologies, [RFC5117]". There's no use of "audio mix*" in RFC5117. If you are referring to "Topo-Mixer" then I think it would be good to mention it. If its something more then we should mention that. Regards, Christian On 12/07/2011 8:36 AM, Stephan Wenger wrote: > Hi all, > I just posted draft-wenger-clue-definitions-01, in an attempt to > reflect the outcome of the mailing list discussions of the last few > months. I'm sure I missed a number of points. Below are those I > didn't miss (from the change log). > Stephan > > > 01: > > removed "stage direction" in "left" "right". Replaced with "to > be interpreted in context". > > clarified "local" to mean "in the same room" per J. Polk email > 6/14/11 > > Consistently refer to "loudspeaker" per Christer's email 6/13/11 > > Added "keyboard" to listed caputure devices per Christer's email > 6/13/11 > > Rendering device: changed "optical" to "visual". Hope Christer finds > this OK. Per Christer's email 6/13/11 > > Note: the other changes proposed by Christer in his 6/13 email appear > to change more than just words but semantics. Not included here as > such semantic changes are best handled in the requirement and other > docs. > > Edt. Note: there have been lengthily discussions about the term > "Participant". One camp wanted the word to refer to human users of > telepresence equipment so to use intuitive language, the other (as > this document) suggests to use the word in the RFC > > Participant defined as per RFC 4353. I think this is what we arrived > at on the mailing list, right? > > Added "Telepresence Extensions" per long "solutions" thread. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From stewe@stewe.org Mon Jul 11 21:28:22 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B1F11E8277 for ; Mon, 11 Jul 2011 21:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.18 X-Spam-Level: X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.419, 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 eL+UkS5qY41C for ; Mon, 11 Jul 2011 21:28:21 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by ietfa.amsl.com (Postfix) with ESMTP id 189E211E8158 for ; Mon, 11 Jul 2011 21:28:19 -0700 (PDT) Received: from [192.168.1.104] (unverified [24.5.184.151]) by stewe.org (SurgeMail 3.9e) with ESMTP id 11934-1743317 for multiple; Tue, 12 Jul 2011 06:28:17 +0200 User-Agent: Microsoft-MacOutlook/14.12.0.110505 Date: Mon, 11 Jul 2011 21:28:05 -0700 From: Stephan Wenger To: Christian Groves , Message-ID: Thread-Topic: [clue] definition-01 posted In-Reply-To: <4E1BC24C.2010705@nteczone.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 24.5.184.151 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.184.151) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [clue] definition-01 posted X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 04:28:22 -0000 Christian, I profoundly apologize for butchering your name. Regarding your other points, let's have a chat in Quebec. At the moment, I'm packing my bags for the JCT-VC video meeting in Torino, and my mind is on that meeting... Stephan On 7.11.2011 20:41 , "Christian Groves" wrote: >Hello Stephan, > >I think you may have given me a name change, I think you are referring >to my (Christian's) email rather than "Christer's". > >A few comments: >------------------------- >My previous comment was: Remote: "A remote can be an Endpoint or an >MCU". I don't think "remote" is being proposed to be a noun by the >definition. Perhaps "A remote can be...."? >This wasn't picked up and I don't think its about changing semantics, >its editorial as it doesn't read right. Some different options: >a) Remote can be used to describe an Endpoint or MCU. >b) A Remote entity can be an Endpoint or an MCU. >c) Delete "A remote can be an Endpoint or MCU". This sentence isn't used >for the local definition, so its questionable why its in the remote >definition. > >Also my previous comment regarding the definition of Audio mixing I >don't think falls into the "semantic/requirements" realm. The definition >of "Audio Mixing" says "... See RTP Topologies, [RFC5117]". There's no >use of "audio mix*" in RFC5117. If you are referring to "Topo-Mixer" >then I think it would be good to mention it. If its something more then >we should mention that. > >Regards, Christian > >On 12/07/2011 8:36 AM, Stephan Wenger wrote: >> Hi all, >> I just posted draft-wenger-clue-definitions-01, in an attempt to >> reflect the outcome of the mailing list discussions of the last few >> months. I'm sure I missed a number of points. Below are those I >> didn't miss (from the change log). >> Stephan >> >> >> 01: >> >> removed "stage direction" in "left" "right". Replaced with "to >> be interpreted in context". >> >> clarified "local" to mean "in the same room" per J. Polk email >> 6/14/11 >> >> Consistently refer to "loudspeaker" per Christer's email 6/13/11 >> >> Added "keyboard" to listed caputure devices per Christer's email >> 6/13/11 >> >> Rendering device: changed "optical" to "visual". Hope Christer finds >> this OK. Per Christer's email 6/13/11 >> >> Note: the other changes proposed by Christer in his 6/13 email appear >> to change more than just words but semantics. Not included here as >> such semantic changes are best handled in the requirement and other >> docs. >> >> Edt. Note: there have been lengthily discussions about the term >> "Participant". One camp wanted the word to refer to human users of >> telepresence equipment so to use intuitive language, the other (as >> this document) suggests to use the word in the RFC >> >> Participant defined as per RFC 4353. I think this is what we arrived >> at on the mailing list, right? >> >> Added "Telepresence Extensions" per long "solutions" thread. >> >> >> _______________________________________________ >> 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 allyn@cisco.com Sun Jul 17 20:29:36 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B203D21F8ADE for ; Sun, 17 Jul 2011 20:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=-3.814, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] 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 KQqSeR1C4+lF for ; Sun, 17 Jul 2011 20:29:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4A821F8ADC for ; Sun, 17 Jul 2011 20:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4223; q=dns/txt; s=iport; t=1310959775; x=1312169375; h=mime-version:subject:date:message-id:from:to:cc; bh=kOHSSrROzyHHDJPvr3WMLik+t9ccixwHrv701/Ez/bE=; b=kzObdL2HFoRfDWZCEq2O013h2WTcENuKNMJuFk6anlFHAB4asIjoAaQx iZLff5poXHFrXafmI/C+QTvwo+cpFha4+ZHQLRC1Y3C9sl5but0IK9ALl 5GwcygRZRoRXJzxUnv9kdaq0kX4tyN0S6SKleI8m2pO8FS/EbTqfcTy0J 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKenI06rRDoJ/2dsb2JhbABTglOlG3etaJ0KhV1fBIdUkByLaw X-IronPort-AV: E=Sophos;i="4.67,220,1309737600"; d="scan'208,217";a="3807096" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2011 03:29:35 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6I3TYYk019248; Mon, 18 Jul 2011 03:29:34 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 17 Jul 2011 20:29:05 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC44FA.D8426145" Date: Sun, 17 Jul 2011 20:29:05 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04F4C582@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements version -03, reqmt- 3a Thread-Index: AcxE+th6jWNgi/LURZm2HKT3yxIbmA== From: "Allyn Romanow (allyn)" To: "Stephan Wenger" X-OriginalArrivalTime: 18 Jul 2011 03:29:05.0171 (UTC) FILETIME=[D8806E30:01CC44FA] Cc: clue@ietf.org Subject: [clue] Requirements version -03, reqmt- 3a X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 03:29:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC44FA.D8426145 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephan,=20 You suggested that it would be better to use SHOULD than must. Unfortunately you couldn't be at the interim meeting to discuss this. Do you want to try an email discussion or wait and talk about it at the upcoming meeting? =20 At the meeting, Roni suggested Stephan's issue may be the distinction between whether the protocol MUST support the capability, or whether the protocol MUST always provide the information -- feeling was that we want the former but not the latter. =20 =20 Thanks, Allyn =20 The solution MUST enable individual audio streams to be associated with one or more video image captures, and individual video image captures to be associated with one or more audio captures, for the purpose of rendering proper position. ------_=_NextPart_001_01CC44FA.D8426145 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephan,

You suggested that it would be better to use SHOULD = than must. Unfortunately you couldn’t be at the interim meeting to = discuss this. Do you want to try an email discussion or wait and talk about it = at the upcoming meeting?

 

At the meeting, Roni = suggested Stephan's issue may be the distinction between whether the protocol MUST support = the capability, or whether the protocol MUST always provide the information = -- feeling was that we want the former but not the latter.

 

 

Thanks,

Allyn

 

The solution MUST enable individual audio streams = to be associated

with one or more video image captures, and = individual video image

captures to be associated with one or more audio = captures, for the

purpose of rendering proper = position.

------_=_NextPart_001_01CC44FA.D8426145-- From pkyzivat@alum.mit.edu Wed Jul 20 17:04:35 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218F221F8ABE for ; Wed, 20 Jul 2011 17:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZm2KZPLr9AV for ; Wed, 20 Jul 2011 17:04:34 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 79A4121F854E for ; Wed, 20 Jul 2011 17:04:30 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta15.westchester.pa.mail.comcast.net with comcast id AQ4E1h0020cZkys5FQ4WyU; Thu, 21 Jul 2011 00:04:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta10.westchester.pa.mail.comcast.net with comcast id AQ4J1h01j0tdiYw3WQ4NCU; Thu, 21 Jul 2011 00:04:27 +0000 Message-ID: <4E276D00.1030802@alum.mit.edu> Date: Wed, 20 Jul 2011 20:04:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] draft-romanow-clue-framework-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, 21 Jul 2011 00:04:35 -0000 (As individual) I have what seems to me to be a fundamental question or misunderstanding about the approach taken where the receiver "configures" the streams to receive from those offered by the sender. I see how this works in a point-to-point configuration. But I don't see how it works with an MCU. In particular, I don't see now mutually exclusive capture sets are selected. Assume that one room has a camera that zooms, and so can offer a capture set with it zoomed and one with it not zoomed. This can be configured for one or the other, once. It can't be configured for one or the other independently for each of the other rooms attached to the MCU. So it appears that the MCU must make the choice of how to configure it. But how does that play out for the other rooms? It seems the MCU will have to make this configuration decision *before* it advertises its capture sets to the other rooms. Hence it won't be able to advertise both variations and so won't hear what the other rooms *would like*. It appears there will be less configurability to endpoints in the MCU case than in the point to point case. Am I missing something? Thanks, Paul From stephane.cazeaux@orange-ftgroup.com Thu Jul 21 04:32:45 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077F221F8B19 for ; Thu, 21 Jul 2011 04:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 X+P26T+Hi-FB for ; Thu, 21 Jul 2011 04:32:44 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id B82D021F88A1 for ; Thu, 21 Jul 2011 04:32:43 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7E799FC400A for ; Thu, 21 Jul 2011 13:32:42 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 7158AFC4009 for ; Thu, 21 Jul 2011 13:32:42 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr ([10.194.32.11]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Jul 2011 13:32:42 +0200 Received: from FTRDMB03.rd.francetelecom.fr ([fe80::4c06:6ece:ed2d:797e]) by FTRDCH01.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Thu, 21 Jul 2011 13:32:41 +0200 From: To: Thread-Topic: Comment on the presentation use case Thread-Index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpA== Date: Thu, 21 Jul 2011 11:32:40 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.193.104] Content-Type: multipart/alternative; boundary="_000_FEE7A6136F518B4B87037A58924AB6B0A89CB7FTRDMB03rdfrancet_" MIME-Version: 1.0 X-OriginalArrivalTime: 21 Jul 2011 11:32:42.0458 (UTC) FILETIME=[E7644BA0:01CC4799] Subject: [clue] Comment on the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 11:32:45 -0000 --_000_FEE7A6136F518B4B87037A58924AB6B0A89CB7FTRDMB03rdfrancet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The presentation use case as described in the use-cases document is based o= n the assumption that the presentation stream relies on a video stream, and= is limited to usage of presentation video streams. But we could also consi= der collaborative use cases, meaningful for telepresence, which are not cov= ered by the existing text. I propose to complete the existing text as follows: " Furthermore, although most today's systems use video streams for presentati= ons, there are use cases where this is not suitable. For example: - The professor which shares an electronic whiteboard (could be a whiteboar= d application on a PC, with screen capture of the PC) where all students ca= n participate. Students will take control of the shared whiteboard in turns= . - In a multipoint meeting, a shared document can be kept always visible in = a screen, while other documents are presented on other screens (with possib= le in turns presentation). For instance, for the purpose of shared design d= ocument, notes taking, polls, etc. A shared document implies that all parti= cipants can modify it in turns. " Stephane. --_000_FEE7A6136F518B4B87037A58924AB6B0A89CB7FTRDMB03rdfrancet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The presentation use case as de= scribed in the use-cases document is based on the assumption that the prese= ntation stream relies on a video stream, and is limited to usage of present= ation video streams. But we could also consider collaborative use cases, meaningful for telepresence, which are n= ot covered by the existing text.

I propose to complete the exist= ing text as follows:

 

“

Furthermore, although most toda= y's systems use video streams for presentations, there are use cases where = this is not suitable. For example:

- The professor which shares an= electronic whiteboard (could be a whiteboard application on a PC, with scr= een capture of the PC) where all students can participate. Students will ta= ke control of the shared whiteboard in turns.

- In a multipoint meeting, a sh= ared document can be kept always visible in a screen, while other documents= are presented on other screens (with possible in turns presentation). For = instance, for the purpose of shared design document, notes taking, polls, etc. A shared document implies that = all participants can modify it in turns.

“=

 

 

Stephane.

--_000_FEE7A6136F518B4B87037A58924AB6B0A89CB7FTRDMB03rdfrancet_-- From apeppere@cisco.com Thu Jul 21 06:19:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB35421F87ED for ; Thu, 21 Jul 2011 06:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3Yo17DeBhMh for ; Thu, 21 Jul 2011 06:19:43 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C7C3B21F87A4 for ; Thu, 21 Jul 2011 06:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=apeppere@cisco.com; l=2523; q=dns/txt; s=iport; t=1311254382; x=1312463982; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ukyrXcxYnom1wAXCXxsdhxouwfWODi0nSbnKLpfx4v8=; b=Uaa6LJb7rexAgIPi6QIjxsPr2S24hX4iOPrhrZNZ+rhJqVfZUn9W4qRz LodFHVHfPKxUJg2IQT6GvEX+rqxPM1cqczMgSz5o814Sc0Ms7QT3qv8GX juVXoSGwINrd514l58USPxMFrfo234XNAu6yAiE6MwvXRa6fWNRZG0aiV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADAnKE6Q/khL/2dsb2JhbABUEKdad6czniWGPgSSboUHix84 Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Jul 2011 13:19:40 +0000 Received: from [10.47.196.246] ([10.47.196.246]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6LDJeIQ022830; Thu, 21 Jul 2011 13:19:40 GMT Message-ID: <4E282773.4040202@cisco.com> Date: Thu, 21 Jul 2011 14:19:47 +0100 From: Andy Pepperell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Paul Kyzivat References: <4E276D00.1030802@alum.mit.edu> In-Reply-To: <4E276D00.1030802@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] draft-romanow-clue-framework-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, 21 Jul 2011 13:19:47 -0000 Hi Paul, I'm happy to have a go at explaining how this case is covered: >Assume that one room has a camera that zooms, and so can offer a capture set with it zoomed and one with it not zoomed. I think more precisely in this case the room could happily a capture set with both the zoomed and not zoomed captures - however, the simultaneous transmission information also supplied by that endpoint would indicate that both could not be provided at the same time. The endpoint would inform the MCU of these restrictions and thereafter it would be up to the MCU to determine which it asked the endpoint for at any given time. The MCU would have the independent task of advertising its own media captures to other connected endpoints, and it could choose whether or not to mirror other endpoints' capture configurations / constraints to other participants. An MCU might choose to always request the zoomed out view, for instance, or do so based on the presence / absence of other multiscreen endpoints in the conference. Hope this helps, Andy Pepperell On 21/07/2011 01:04, Paul Kyzivat wrote: > (As individual) > > I have what seems to me to be a fundamental question or > misunderstanding about the approach taken where the receiver > "configures" the streams to receive from those offered by the sender. > > I see how this works in a point-to-point configuration. > But I don't see how it works with an MCU. In particular, I don't see > now mutually exclusive capture sets are selected. > > Assume that one room has a camera that zooms, and so can offer a > capture set with it zoomed and one with it not zoomed. This can be > configured for one or the other, once. It can't be configured for one > or the other independently for each of the other rooms attached to the > MCU. So it appears that the MCU must make the choice of how to > configure it. But how does that play out for the other rooms? > > It seems the MCU will have to make this configuration decision > *before* it advertises its capture sets to the other rooms. Hence it > won't be able to advertise both variations and so won't hear what the > other rooms *would like*. > > It appears there will be less configurability to endpoints in the MCU > case than in the point to point case. > Am I missing something? > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Jul 21 06:40:40 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A17421F8B12 for ; Thu, 21 Jul 2011 06:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 tkEnfCa5-Ew6 for ; Thu, 21 Jul 2011 06:40:36 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 19E0E21F8B11 for ; Thu, 21 Jul 2011 06:40:35 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id Adgc1h0080QuhwU58dgcvN; Thu, 21 Jul 2011 13:40:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta02.westchester.pa.mail.comcast.net with comcast id AdgZ1h00e0tdiYw3NdgZoD; Thu, 21 Jul 2011 13:40:34 +0000 Message-ID: <4E282C4E.3040106@alum.mit.edu> Date: Thu, 21 Jul 2011 09:40:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Andy Pepperell References: <4E276D00.1030802@alum.mit.edu> <4E282773.4040202@cisco.com> In-Reply-To: <4E282773.4040202@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] draft-romanow-clue-framework-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, 21 Jul 2011 13:40:40 -0000 On 7/21/11 9:19 AM, Andy Pepperell wrote: > Hi Paul, > > I'm happy to have a go at explaining how this case is covered: > > >Assume that one room has a camera that zooms, and so can offer a > capture set with it zoomed and one with it not zoomed. > > I think more precisely in this case the room could happily a capture set > with both the zoomed and not zoomed captures - however, the simultaneous > transmission information also supplied by that endpoint would indicate > that both could not be provided at the same time. > > The endpoint would inform the MCU of these restrictions and thereafter > it would be up to the MCU to determine which it asked the endpoint for > at any given time. The MCU would have the independent task of > advertising its own media captures to other connected endpoints, and it > could choose whether or not to mirror other endpoints' capture > configurations / constraints to other participants. An MCU might choose > to always request the zoomed out view, for instance, or do so based on > the presence / absence of other multiscreen endpoints in the conference. Yes, I see it could do that. But it seems difficult for it to do so based on the desires of the other endpoints. It can't easily solicit those desires because it can't advertise both alternatives. (If it were to do so it would open the possibility that one room would configure a group containing the zoomed view, and some other room would configure a group with the unzoomed view.) So the MCU is left to choose on its own and then advertise only groups based on that choice. The other rooms then have no indication that the choice not taken is even a possibility. Thanks, Paul > Hope this helps, > > Andy Pepperell > > > On 21/07/2011 01:04, Paul Kyzivat wrote: >> (As individual) >> >> I have what seems to me to be a fundamental question or >> misunderstanding about the approach taken where the receiver >> "configures" the streams to receive from those offered by the sender. >> >> I see how this works in a point-to-point configuration. >> But I don't see how it works with an MCU. In particular, I don't see >> now mutually exclusive capture sets are selected. >> >> Assume that one room has a camera that zooms, and so can offer a >> capture set with it zoomed and one with it not zoomed. This can be >> configured for one or the other, once. It can't be configured for one >> or the other independently for each of the other rooms attached to the >> MCU. So it appears that the MCU must make the choice of how to >> configure it. But how does that play out for the other rooms? >> >> It seems the MCU will have to make this configuration decision >> *before* it advertises its capture sets to the other rooms. Hence it >> won't be able to advertise both variations and so won't hear what the >> other rooms *would like*. >> >> It appears there will be less configurability to endpoints in the MCU >> case than in the point to point case. >> Am I missing something? >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From mary.ietf.barnes@gmail.com Mon Jul 25 11:24:02 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF9611E8089 for ; Mon, 25 Jul 2011 11:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.416 X-Spam-Level: X-Spam-Status: No, score=-103.416 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 y7y6Np53N29l for ; Mon, 25 Jul 2011 11:24:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F2F4611E808A for ; Mon, 25 Jul 2011 11:23:58 -0700 (PDT) Received: by vxi40 with SMTP id 40so3960439vxi.31 for ; Mon, 25 Jul 2011 11:23:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZHJgAalgDcMDhuc5p+I43BMY+xAQOn9yomtiNyD1rVE=; b=TBrqXk6vYfn/1jbD6rgK26mtS735npFmgWZHPMUfAQsN7DA1yqnKqUkixYnOJ5+vQ4 jR7+tutHeZoOqQwjxk0Cy4pWvqjgN7E6pLFfEpz/6XOweYHIb582ozK0doeX+3kGrO51 RihIp46LeOr+ZDd6ks6qX+Pr8WuXkOLaXsahs= MIME-Version: 1.0 Received: by 10.52.93.201 with SMTP id cw9mr4867235vdb.250.1311618238279; Mon, 25 Jul 2011 11:23:58 -0700 (PDT) Received: by 10.52.167.34 with HTTP; Mon, 25 Jul 2011 11:23:58 -0700 (PDT) Date: Mon, 25 Jul 2011 13:23:58 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307cfeb62c716404a8e8eb6f Subject: [clue] Adhoc for "Rendering Negotiation" discussion Tuesday, July 26th, 7:30 am, Room 2103 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 18:24:02 -0000 --20cf307cfeb62c716404a8e8eb6f Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Per the discussion during the interim meeting, an adhoc has been scheduled for the CLUE WG for tomorrow morning. It will start at 7:30 and take a short break around 8:00ish for folks to get breakfast (or we can plan to stop earlier so folks can eat). The agenda is included in the CLUE WG agenda for the official session on Thursday: http://www.ietf.org/proceedings/81/agenda/clue.html Right now, the link to the charts points to the version from the interim. We may upload an updated version before tomorrow. If you do download the charts, make sure to refresh your browser, so you'll get the latest version. Regards, Mary DISPATCH WG co-chair --20cf307cfeb62c716404a8e8eb6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

Per the discussion during the interim meeting,= an adhoc has been scheduled for the CLUE WG for tomorrow morning. =A0It wi= ll start at 7:30 and take a short break around 8:00ish for folks to get bre= akfast (or we can plan to stop earlier so folks can eat). =A0 =A0The agenda= is included in the CLUE WG agenda for the official session on Thursday:

= Right now, the link to the charts points to the version from the interim. = =A0We may upload an updated version before tomorrow. If you do download the= charts, make sure to refresh your browser, so you'll get the latest ve= rsion.

Regards,
Mary
DISPATCH WG co-chair<= /div> --20cf307cfeb62c716404a8e8eb6f-- From mary.ietf.barnes@gmail.com Mon Jul 25 11:36:58 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C50721F8C20 for ; Mon, 25 Jul 2011 11:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.426 X-Spam-Level: X-Spam-Status: No, score=-103.426 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ptyfnVKn5bcF for ; Mon, 25 Jul 2011 11:36:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C479821F8C1F for ; Mon, 25 Jul 2011 11:36:57 -0700 (PDT) Received: by vxi40 with SMTP id 40so3970451vxi.31 for ; Mon, 25 Jul 2011 11:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0xyB43XdxyO9GpR+nF1gc1oTXN0/BhrFpRS7DwXLcGU=; b=mOFwkuG77TmFEKSooJXj5TUxvbtGf3DbfhEUdGaXz5LqkMCN6bc5OlJ5Xfjdc84TVB XmwY9YPpv5RkE/uOOpO5Kzah6vnvFYNjftBYrB50bZmK8iEShd2O8bJGFnhLlPUqo9yQ K7PnIlFljPTJY2oKE942B8QTnMoV4Fts1Nv/c= MIME-Version: 1.0 Received: by 10.52.23.10 with SMTP id i10mr4848866vdf.317.1311619016847; Mon, 25 Jul 2011 11:36:56 -0700 (PDT) Received: by 10.52.167.34 with HTTP; Mon, 25 Jul 2011 11:36:56 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Jul 2011 13:36:56 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=20cf307ca572946f7a04a8e9190e Subject: Re: [clue] Adhoc for "Rendering Negotiation" discussion Tuesday, July 26th, 7:30 am, Room 2103 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 18:36:58 -0000 --20cf307ca572946f7a04a8e9190e Content-Type: text/plain; charset=ISO-8859-1 For folks that might have missed the room # in the Subject line, it's in room 2103. On Mon, Jul 25, 2011 at 1:23 PM, Mary Barnes wrote: > Hi folks, > > Per the discussion during the interim meeting, an adhoc has been scheduled > for the CLUE WG for tomorrow morning. It will start at 7:30 and take a > short break around 8:00ish for folks to get breakfast (or we can plan to > stop earlier so folks can eat). The agenda is included in the CLUE WG > agenda for the official session on Thursday: > http://www.ietf.org/proceedings/81/agenda/clue.html > > Right now, the link to the charts points to the version from the interim. > We may upload an updated version before tomorrow. If you do download the > charts, make sure to refresh your browser, so you'll get the latest version. > > Regards, > Mary > DISPATCH WG co-chair > --20cf307ca572946f7a04a8e9190e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable For folks that might have missed the room # in the Subject line, it's i= n room 2103.

On Mon, Jul 25, 2011 at 1:23= PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
Hi folks,

Per the discus= sion during the interim meeting, an adhoc has been scheduled for the CLUE W= G for tomorrow morning. =A0It will start at 7:30 and take a short break aro= und 8:00ish for folks to get breakfast (or we can plan to stop earlier so f= olks can eat). =A0 =A0The agenda is included in the CLUE WG agenda for the = official session on Thursday:

Right now, the link to the charts points to the version f= rom the interim. =A0We may upload an updated version before tomorrow. If yo= u do download the charts, make sure to refresh your browser, so you'll = get the latest version.

Regards,
Mary
DISPATCH WG co-chair<= /div>

--20cf307ca572946f7a04a8e9190e-- From john.elwell@siemens-enterprise.com Tue Jul 26 05:32:57 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9312121F8BD2 for ; Tue, 26 Jul 2011 05:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.826 X-Spam-Level: X-Spam-Status: No, score=-103.826 tagged_above=-999 required=5 tests=[AWL=-1.227, 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 ZZsSA0pfxoxh for ; Tue, 26 Jul 2011 05:32:57 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id CCBEA21F8BB9 for ; Tue, 26 Jul 2011 05:32:56 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 604131EB8418 for ; Tue, 26 Jul 2011 14:32:55 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 26 Jul 2011 14:32:55 +0200 From: "Elwell, John" To: "clue@ietf.org" Date: Tue, 26 Jul 2011 14:32:53 +0200 Thread-Topic: Comment on rendering slides Thread-Index: AcxLkCH6LYKpHXGfR12MLIQ5EVqQGg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 12:32:57 -0000 Based on this morning's discussion, I have a problem with the proposal on t= he last slide: "REQ-x: It MUST be possible for a client to indicate, per media stream, sup= ported rendering type(s). REQ-y: It MUST be possible to inform a client, per media stream, the render= ing type(s) applied to the stream. " I believe this is a more asymmetric problem, and perhaps needs to be expres= sed in terms of: "REQ-x: It MUST be possible for a client to indicate, per media stream, ren= dering type(s) it is able to transmit. =A0 REQ-y: It MUST be possible to inform a client, per media stream, the render= ing type(s) that can be received."=20 (where the media types to be received would be selected from those able to = be transmitted by the peer) Notwithstanding, of course, that we need to explore more use cases to see w= hether this really fits. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. From mary.ietf.barnes@gmail.com Tue Jul 26 06:37:24 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2008121F8B1B for ; Tue, 26 Jul 2011 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.429 X-Spam-Level: X-Spam-Status: No, score=-103.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cw2Xqr0iVccV for ; Tue, 26 Jul 2011 06:37:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 864C921F8B19 for ; Tue, 26 Jul 2011 06:37:23 -0700 (PDT) Received: by vws12 with SMTP id 12so398734vws.31 for ; Tue, 26 Jul 2011 06:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=mU8x8QVXs75acdO2ACQ1tIY0FEWbwSmf7NThRj3sBwI=; b=GVk84/z4/lqNW4unlbzbzBhKDVszrtlPpGlRKmYfDvfQvdygzAA7w3F2FVDOGmxumM o6V5sTrT4Ygshxn7n94YZR6qLcde9hufCUlicC8TPTGr14Upe9PqD6cY6Xlfl1iau29n to5B2ICi+50y7BmBn0zCKv5Z5IwNyBX7Oj28Q= MIME-Version: 1.0 Received: by 10.52.183.42 with SMTP id ej10mr5544674vdc.451.1311687442848; Tue, 26 Jul 2011 06:37:22 -0700 (PDT) Received: by 10.52.167.34 with HTTP; Tue, 26 Jul 2011 06:37:22 -0700 (PDT) Date: Tue, 26 Jul 2011 08:37:22 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=bcaec548a017165d9a04a8f90899 Subject: [clue] Thursday's meeting agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 13:37:24 -0000 --bcaec548a017165d9a04a8f90899 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Per the agenda, we will be spending a fair amount of time on the new framework document: http://www.ietf.org/proceedings/81/agenda/clue.html Since this is a new document and it would really facilitate the discussion if follks could make sure to read that document before the meeting. As an FYI, the charts for the requirements and the framework are available in the meeting materials: https://datatracker.ietf.org/meeting/81/materials.html We will add Stephan's charts for the definitions and Christer's updated charts from this mornings adhoc soon. Regards, Mary. --bcaec548a017165d9a04a8f90899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Per the agenda, we will be spending a fair amoun= t of time on the new framework document:
=A0
Since this is a new document and it would really facilit= ate the discussion if follks could make sure to read that document before t= he meeting. =A0

As an FYI, the charts for the requ= irements and the framework are available in the meeting materials:

We will add Stephan's charts for the definitions and Christer'= ;s updated charts from this mornings adhoc soon.=A0

Regards,
Mary.
--bcaec548a017165d9a04a8f90899-- From eckelcu@cisco.com Tue Jul 26 07:51:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB721F8CB4 for ; Tue, 26 Jul 2011 07:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=-0.422, 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 a2kdje74WMGb for ; Tue, 26 Jul 2011 07:51:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8064821F8AA8 for ; Tue, 26 Jul 2011 07:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3227; q=dns/txt; s=iport; t=1311691899; x=1312901499; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=lx9jaDmcXuxilwpZndNP3OGu9+dQVnq9647EgqGrEOc=; b=LKGNeoPfZX8gOaLCoLEd4tQj955Nkq9garKw88hZt35fC4s/LsJkXuZk qDonibevcIe9ZB2+4rIJ1uKYSYCULrILP5AU3GLkJu0Z8IDxKQB/MzPiD 60pl/32tX3ltpUvF3t+UPHuENMxa/Krq3dnsMy772K7Z0VwhQ+BRXQ40g Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4AAHrTLk6rRDoG/2dsb2JhbAA2AQEBAQMBAQERASEKOhcFAgEJEQQBAQsGIwEGARMYIw4IAQEFARYMG5dcj1p3iQCjBZ5hhWFfBIdXkCuLcA X-IronPort-AV: E=Sophos;i="4.67,269,1309737600"; d="scan'208";a="6509401" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-6.cisco.com with ESMTP; 26 Jul 2011 14:51:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6QEpbKG008784; Tue, 26 Jul 2011 14:51:38 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Jul 2011 07:51:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Jul 2011 07:51:30 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comment on rendering slides Thread-Index: AcxLkCH6LYKpHXGfR12MLIQ5EVqQGgAEVyNg References: From: "Charles Eckel (eckelcu)" To: "Elwell, John" , X-OriginalArrivalTime: 26 Jul 2011 14:51:33.0545 (UTC) FILETIME=[82F07190:01CC4BA3] Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:51:43 -0000 I would prefer to continue to use the existing SDP mechanism to describe what an endpoint is capable of receiving. I think the existing framework draft provides a mechanism for a sender to indicate what it can send, and for a receiver to select which of those it wants to receive. As for asymmetry, I read the framework as allowing each side to act as a sender and a receiver, facilitating asymmetry. If others think this is not the case, then I agree with John that we need to clarify that. What I think is missing is: - a mechanism for a receiver to indicate a preference for, or a request for, a specific rendering, or layout, or format (i.e. not just that I want one H.264 video stream and one G.722 audio stream, but what I want each of those to contain).=20 The main benefit of doing this is that it might allow a sender to tailor its description of what it can send to include options that the receiver requested, as opposed to the sender trying to list every single possible combination it can imagine.=20 There are many ways to do this, and I do not want to get into the details here, but if we agree that we need a mechanism for a receiver to advertise its preference or request something specific from the sender along these line, then I think we can cover Christer's rendering use cases as well as some of the use cases I mentioned previously regarding composition. If we list out the use cases, we can make sure this mechanism is sufficient to address all of them. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Tuesday, July 26, 2011 8:33 AM > To: clue@ietf.org > Subject: [clue] Comment on rendering slides >=20 > Based on this morning's discussion, I have a problem with the proposal on the last slide: >=20 > "REQ-x: It MUST be possible for a client to indicate, per media stream, supported rendering > type(s). > REQ-y: It MUST be possible to inform a client, per media stream, the rendering type(s) applied to > the stream. " >=20 > I believe this is a more asymmetric problem, and perhaps needs to be expressed in terms of: > "REQ-x: It MUST be possible for a client to indicate, per media stream, rendering type(s) it is > able to transmit. >=20 > REQ-y: It MUST be possible to inform a client, per media stream, the rendering type(s) that can > be received." >=20 > (where the media types to be received would be selected from those able to be transmitted by the peer) >=20 > Notwithstanding, of course, that we need to explore more use cases to see whether this really fits. >=20 > John >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From john.elwell@siemens-enterprise.com Tue Jul 26 08:24:01 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC8411E80C1 for ; Tue, 26 Jul 2011 08:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.807 X-Spam-Level: X-Spam-Status: No, score=-103.807 tagged_above=-999 required=5 tests=[AWL=-1.208, 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 N2u0yrGiU0t2 for ; Tue, 26 Jul 2011 08:24:01 -0700 (PDT) Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8385E11E8131 for ; Tue, 26 Jul 2011 08:23:59 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 14C5C1EB846B; Tue, 26 Jul 2011 17:23:58 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 26 Jul 2011 17:23:58 +0200 From: "Elwell, John" To: "Charles Eckel (eckelcu)" , "clue@ietf.org" Date: Tue, 26 Jul 2011 17:23:55 +0200 Thread-Topic: [clue] Comment on rendering slides Thread-Index: AcxLkCH6LYKpHXGfR12MLIQ5EVqQGgAEVyNgAAEW70A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 15:24:01 -0000 Yes, I think the framework does provide for asymmetry, so perhaps the need = to refine these requirements is moot. As to whether the current framework i= s mappable onto offer-answer, I am not sure. Probably by using >1 offer-ans= wer cycles it could be done. The question of whether we need to start with the receiver saying what it c= an receive (and the sender choosing what to select what to send on that bas= is) or start with the sender saying what it can send (and the receiver choo= sing what it wants to receive from that list) is a valid question and I am = not sure I understand what the right answer is. For example, a receiver wit= h a large screen perhaps has unlimited capabilities as to what it can displ= ay on that screen, so negotiation really needs to start with the sender say= ing what it can send and the receiver making a selection. On the other hand= , a receiver with a single speaker might want to start by saying it can rec= eive a single audio stream, and the sender selects the most appropriate str= eam to send out of those it is able to capture. Perhaps the framework has t= he necessary flexibility - I am not sure. John=20 > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 > Sent: 26 July 2011 15:52 > To: Elwell, John; clue@ietf.org > Subject: RE: [clue] Comment on rendering slides >=20 > I would prefer to continue to use the existing SDP mechanism=20 > to describe > what an endpoint is capable of receiving. I think the=20 > existing framework > draft provides a mechanism for a sender to indicate what it can send, > and for a receiver to select which of those it wants to receive. > As for asymmetry, I read the framework as allowing each side=20 > to act as a > sender and a receiver, facilitating asymmetry. If others think this is > not the case, then I agree with John that we need to clarify that. >=20 > What I think is missing is: > - a mechanism for a receiver to indicate a preference for, or=20 > a request > for, a specific rendering, or layout, or format (i.e. not just that I > want one H.264 video stream and one G.722 audio stream, but=20 > what I want > each of those to contain).=20 >=20 > The main benefit of doing this is that it might allow a=20 > sender to tailor > its description of what it can send to include options that=20 > the receiver > requested, as opposed to the sender trying to list every=20 > single possible > combination it can imagine.=20 > There are many ways to do this, and I do not want to get into the > details here, but if we agree that we need a mechanism for a=20 > receiver to > advertise its preference or request something specific from the sender > along these line, then I think we can cover Christer's rendering use > cases as well as some of the use cases I mentioned previously=20 > regarding > composition. If we list out the use cases, we can make sure this > mechanism is sufficient to address all of them. >=20 > Cheers, > Charles >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Elwell, John > > Sent: Tuesday, July 26, 2011 8:33 AM > > To: clue@ietf.org > > Subject: [clue] Comment on rendering slides > >=20 > > Based on this morning's discussion, I have a problem with=20 > the proposal > on the last slide: > >=20 > > "REQ-x: It MUST be possible for a client to indicate, per media > stream, supported rendering > > type(s). > > REQ-y: It MUST be possible to inform a client, per media > stream, the rendering type(s) applied to > > the stream. " > >=20 > > I believe this is a more asymmetric problem, and perhaps needs to be > expressed in terms of: > > "REQ-x: It MUST be possible for a client to indicate, per media > stream, rendering type(s) it is > > able to transmit. > >=20 > > REQ-y: It MUST be possible to inform a client, per media > stream, the rendering type(s) that can > > be received." > >=20 > > (where the media types to be received would be selected from those > able to be transmitted by the peer) > >=20 > > Notwithstanding, of course, that we need to explore more=20 > use cases to > see whether this really fits. > >=20 > > John > >=20 > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > >=20 > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton=20 > Keynes, MK15 > 0DJ. > > Registered No: 5903714, England. > >=20 > > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. > >=20 > >=20 > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > = From pkyzivat@alum.mit.edu Tue Jul 26 08:35:32 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAF821F869C for ; Tue, 26 Jul 2011 08:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 OEWsamNa2WYy for ; Tue, 26 Jul 2011 08:35:31 -0700 (PDT) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF9611E807C for ; Tue, 26 Jul 2011 08:35:31 -0700 (PDT) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta13.emeryville.ca.mail.comcast.net with comcast id CfYC1h0080lTkoCADfbUCJ; Tue, 26 Jul 2011 15:35:28 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta04.emeryville.ca.mail.comcast.net with comcast id CfbK1h01E5EhBnE8QfbP4c; Tue, 26 Jul 2011 15:35:28 +0000 Message-ID: <4E2EDEB7.1080708@alum.mit.edu> Date: Tue, 26 Jul 2011 11:35:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 15:35:32 -0000 (as individual) I largely agree with Charles. ISTM that what this is developing into is a more extensive negotiation than is possible with one round of o/a exchange. Conceivably this could be done using multiple o/a exchanges, but that may not be the best way. It seems to me that when a box advertises what it can provide, it probably doesn't want to be required to have all of those already available. IOW, the advertisement is like a menu from which the recipient can order, rather than a buffet from which the recipient can take things. (An SDP offer is a buffet.) The sender can then defer cooking the item until it knows it has an order. The other issue is whether the sender can realistically enumerate the entire menu. Perhaps there are too many variations possible. In that case the "customer" may want to request something that is not on the menu. Maybe that then gets added to the menu, and maybe not. Whether we need to go that way may depend on the mechanism used to deliver the advertisement/menu. If its done via SDP then the size of the menu is probably quite limited. If it is done some other way, then maybe not. Thanks, Paul On 7/26/11 10:51 AM, Charles Eckel (eckelcu) wrote: > I would prefer to continue to use the existing SDP mechanism to describe > what an endpoint is capable of receiving. I think the existing framework > draft provides a mechanism for a sender to indicate what it can send, > and for a receiver to select which of those it wants to receive. > As for asymmetry, I read the framework as allowing each side to act as a > sender and a receiver, facilitating asymmetry. If others think this is > not the case, then I agree with John that we need to clarify that. > > What I think is missing is: > - a mechanism for a receiver to indicate a preference for, or a request > for, a specific rendering, or layout, or format (i.e. not just that I > want one H.264 video stream and one G.722 audio stream, but what I want > each of those to contain). > > The main benefit of doing this is that it might allow a sender to tailor > its description of what it can send to include options that the receiver > requested, as opposed to the sender trying to list every single possible > combination it can imagine. > There are many ways to do this, and I do not want to get into the > details here, but if we agree that we need a mechanism for a receiver to > advertise its preference or request something specific from the sender > along these line, then I think we can cover Christer's rendering use > cases as well as some of the use cases I mentioned previously regarding > composition. If we list out the use cases, we can make sure this > mechanism is sufficient to address all of them. > > Cheers, > Charles > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Elwell, John >> Sent: Tuesday, July 26, 2011 8:33 AM >> To: clue@ietf.org >> Subject: [clue] Comment on rendering slides >> >> Based on this morning's discussion, I have a problem with the proposal > on the last slide: >> >> "REQ-x: It MUST be possible for a client to indicate, per media > stream, supported rendering >> type(s). >> REQ-y: It MUST be possible to inform a client, per media > stream, the rendering type(s) applied to >> the stream. " >> >> I believe this is a more asymmetric problem, and perhaps needs to be > expressed in terms of: >> "REQ-x: It MUST be possible for a client to indicate, per media > stream, rendering type(s) it is >> able to transmit. >> >> REQ-y: It MUST be possible to inform a client, per media > stream, the rendering type(s) that can >> be received." >> >> (where the media types to be received would be selected from those > able to be transmitted by the peer) >> >> Notwithstanding, of course, that we need to explore more use cases to > see whether this really fits. >> >> John >> >> John Elwell >> Tel: +44 1908 817801 (office and mobile) >> Email: john.elwell@siemens-enterprise.com >> http://www.siemens-enterprise.com/uk/ >> >> Siemens Enterprise Communications Limited. >> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. >> Registered No: 5903714, England. >> >> Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. >> >> >> _______________________________________________ >> 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 Jul 26 14:43:31 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B95C5E8005 for ; Tue, 26 Jul 2011 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09RVZfi70K90 for ; Tue, 26 Jul 2011 14:43:30 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 4458E5E8002 for ; Tue, 26 Jul 2011 14:43:27 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by Crpehubprd01.polycom.com ([fe80::27:216a:613a:350c%13]) with mapi; Tue, 26 Jul 2011 14:43:27 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 26 Jul 2011 14:43:25 -0700 Thread-Topic: [clue] Comment on rendering slides Thread-Index: AcxLqbB+ZnGIXe7DQw2JUp54PzZQPQAMRgKA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802559@CRPMBOXPRD01.polycom.com> References: <4E2EDEB7.1080708@alum.mit.edu> In-Reply-To: <4E2EDEB7.1080708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 21:43:31 -0000 I think we are really talking about draft-romanow-clue-framework-00 and not= the rendering slides, but I left the subject line the same :) Yes, the framework allows both sides of an exchange to act as both a Media = Provider (sender) and a Media Consumer (receiver), with a separate dialog f= or each direction, so the resulting media flows can be asymmetric. As for the receiver indicating preferences up front, yes, it is partly ther= e in the document, that is what the "hints" mentioned in section 7 are for.= The concept is there, but exactly what to do with it is not yet fleshed o= ut. And for the receiver indicating what it wants the streams to contain, that = is partly there too if the sender advertises choices that have different at= tributes. So for example a receiver could choose between a "composed" vide= o stream and a "switched" video stream. Exactly how the composition and sw= itching is done is not specified in the framework. If there is a need to e= xchange this information, perhaps it could be added, but I don't think the = use case document has any cases yet where this would be required, and I did= n't see it in the requirements document either. The use case document also mentions ability to choose media from a specific= source, for example I might want to always see a particular person in the = conference even though that person rarely speaks. This type of source sele= ction is not yet covered in the framework. For other types of source selec= tion, I think we need more use cases to inform requirements. I'm not sure either if this framework can or should be mapped on to SDP off= er/answer. That needs further discussion. Mark Duckworth > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, July 26, 2011 11:35 AM > To: clue@ietf.org > Subject: Re: [clue] Comment on rendering slides >=20 > (as individual) >=20 > I largely agree with Charles. >=20 > ISTM that what this is developing into is a more extensive negotiation > than is possible with one round of o/a exchange. >=20 > Conceivably this could be done using multiple o/a exchanges, but that > may not be the best way. >=20 > It seems to me that when a box advertises what it can provide, it > probably doesn't want to be required to have all of those already > available. IOW, the advertisement is like a menu from which the > recipient can order, rather than a buffet from which the recipient can > take things. (An SDP offer is a buffet.) The sender can then defer > cooking the item until it knows it has an order. >=20 > The other issue is whether the sender can realistically enumerate the > entire menu. Perhaps there are too many variations possible. In that > case the "customer" may want to request something that is not on the > menu. Maybe that then gets added to the menu, and maybe not. >=20 > Whether we need to go that way may depend on the mechanism used to > deliver the advertisement/menu. If its done via SDP then the size of > the > menu is probably quite limited. If it is done some other way, then > maybe > not. >=20 > Thanks, > Paul >=20 > On 7/26/11 10:51 AM, Charles Eckel (eckelcu) wrote: > > I would prefer to continue to use the existing SDP mechanism to > describe > > what an endpoint is capable of receiving. I think the existing > framework > > draft provides a mechanism for a sender to indicate what it can send, > > and for a receiver to select which of those it wants to receive. > > As for asymmetry, I read the framework as allowing each side to act > as a > > sender and a receiver, facilitating asymmetry. If others think this > is > > not the case, then I agree with John that we need to clarify that. > > > > What I think is missing is: > > - a mechanism for a receiver to indicate a preference for, or a > request > > for, a specific rendering, or layout, or format (i.e. not just that I > > want one H.264 video stream and one G.722 audio stream, but what I > want > > each of those to contain). > > > > The main benefit of doing this is that it might allow a sender to > tailor > > its description of what it can send to include options that the > receiver > > requested, as opposed to the sender trying to list every single > possible > > combination it can imagine. > > There are many ways to do this, and I do not want to get into the > > details here, but if we agree that we need a mechanism for a receiver > to > > advertise its preference or request something specific from the > sender > > along these line, then I think we can cover Christer's rendering use > > cases as well as some of the use cases I mentioned previously > regarding > > composition. If we list out the use cases, we can make sure this > > mechanism is sufficient to address all of them. > > > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > > Of Elwell, John > >> Sent: Tuesday, July 26, 2011 8:33 AM > >> To: clue@ietf.org > >> Subject: [clue] Comment on rendering slides > >> > >> Based on this morning's discussion, I have a problem with the > proposal > > on the last slide: > >> > >> "REQ-x: It MUST be possible for a client to indicate, per media > > stream, supported rendering > >> type(s). > >> REQ-y: It MUST be possible to inform a client, per media > > stream, the rendering type(s) applied to > >> the stream. " > >> > >> I believe this is a more asymmetric problem, and perhaps needs to be > > expressed in terms of: > >> "REQ-x: It MUST be possible for a client to indicate, per media > > stream, rendering type(s) it is > >> able to transmit. > >> > >> REQ-y: It MUST be possible to inform a client, per media > > stream, the rendering type(s) that can > >> be received." > >> > >> (where the media types to be received would be selected from those > > able to be transmitted by the peer) > >> > >> Notwithstanding, of course, that we need to explore more use cases > to > > see whether this really fits. > >> > >> John > >> > >> John Elwell > >> Tel: +44 1908 817801 (office and mobile) > >> Email: john.elwell@siemens-enterprise.com > >> http://www.siemens-enterprise.com/uk/ > >> > >> Siemens Enterprise Communications Limited. > >> Registered office: Brickhill Street, Willen Lake, Milton Keynes, > MK15 > > 0DJ. > >> Registered No: 5903714, England. > >> > >> Siemens Enterprise Communications Limited is a Trademark Licensee of > > Siemens AG. > >> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Tue Jul 26 21:08:12 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423B85E801F for ; Tue, 26 Jul 2011 21:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 oN+BE-4zgMO3 for ; Tue, 26 Jul 2011 21:08:11 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 040155E801C for ; Tue, 26 Jul 2011 21:08:11 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOZ00FIA4SPW8@szxga05-in.huawei.com> for clue@ietf.org; Wed, 27 Jul 2011 12:07:37 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOZ00J8O4SPML@szxga05-in.huawei.com> for clue@ietf.org; Wed, 27 Jul 2011 12:07:37 +0800 (CST) Received: from windows8d787f9 (dhcp-438f.meeting.ietf.org [130.129.67.143]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LOZ00GP94SMEM@szxml11-in.huawei.com>; Wed, 27 Jul 2011 12:07:37 +0800 (CST) Date: Wed, 27 Jul 2011 07:04:55 +0300 From: Roni Even In-reply-to: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04D45819@xmb-sjc-221.amer.cisco.com> To: "'Allyn Romanow (allyn)'" , clue@ietf.org Message-id: <003a01cc4c12$59904090$0cb0c1b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acw5yGOQjEx2NapwSjuqXrun//JqxgAAArYABJDNY4A= References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04D45819@xmb-sjc-221.amer.cisco.com> Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-framework-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 04:08:12 -0000 Hi, Found some time to review the draft, it is a good start but I think it needs more work. Some comments ( the one from 5 to 8 may look similar but they are all about the relation between sender and receiver and captures sets as appear in the draft) 1. This is the major one. I saw "VC0- (the left camera stream), encoding group:EG0, attributes:purpose=main;auto-switched:no" and "VC5- (the zoomed out view of all people in the room ), encoding group:EG1, attributes: purpose=main;auto-switched:no". How do you encode in the messge (the left camera stream) or (the zoomed out view of all people in the room). How do you define such information. Without this definition the rest of the syntax is not enough to understand the offers. 2. in the introduction section it says that this is the basic approach and mechanism and that next versions will address more use cases. What is next version, are we going to publish only basic mechanism according to this draft and have the other in a different draft or is this going to be in new version of the current draft-romanow-clue-framework 3. In the definition section there is no definition to media stream that is used in it. 4. The capture set definition "includes Media Captures that all represent some aspect of the same Capture Scene. The items (rows) in a Capture Set represent different alternatives for representing the same Capture Scene.". Reading the description I assume that a capture set includes the layout from the sender perspective and it provide information about the layout or geometry as well as the content of each capture device. Is this true 5. If 4 is correct than in section 6.3 "A media receiver could choose one row of each media type (e.g., audio and video) from a capture set. For example a three stream receiver could choose the first video row plus the audio row, while a single stream receiver could choose the second or third video row plus the audio row." I was wondering how can a receiver select just one capture stream from the capture set if not specified by itself, like just the left camera or from the example in section 7.1 "{VC0, VC1, VC2}" just VC0. 6. The text in section 6.3 "An MCU receiver might choose to receive multiple rows". I thought that rows are physical simultaneity so cannot be sent at the same time. 7. My understanding from section 4 and 5 "The protocol resulting from the framework will be declarative rather than negotiative." is that the sender sends the list of capture set and may send anything from it. I do not see how the receiver selects the capture set it wants to receive now or a subset from it (my question 5). Yet section 6.3 says that the receiver can chose a capture set from all the offered ones. So is this a negotiation? Defiantly if it can ask for a capture set that will have only a subset of the captures in a row. 8. More on this, in section 7.1 "{VC0, VC3, VC2}" is says "both VC0 and VC2 are redundant if VC3 is included". What does redundant mean, that VC and VC2 are not sent or that the receiver can say it wants to receive {VC3} or {VC0, VC3) 9. In A.5 how is this parameter used? Regards Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Allyn Romanow (allyn) > Sent: Monday, July 04, 2011 12:32 AM > To: clue@ietf.org > Subject: [clue] FW: New Version Notification for draft-romanow-clue- > framework-00.txt > > Folks, > > A first draft for the framework has just been posted. > > Best regards, > Allyn > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Sunday, July 03, 2011 2:30 PM > To: Allyn Romanow (allyn) > Cc: mark.duckworth@polycom.com; Allyn Romanow (allyn); Andrew Pepperell > (apeppere); mark.gorzynski@hp.com; bbaldino@polycom.com > Subject: New Version Notification for draft-romanow-clue-framework- > 00.txt > > A new version of I-D, draft-romanow-clue-framework-00.txt has been > successfully submitted by Allyn Romanow and posted to the IETF > repository. > > Filename: draft-romanow-clue-framework > Revision: 00 > Title: Framework for Telepresence Multi-Streams > Creation date: 2011-07-03 > WG ID: Individual Submission > Number of pages: 31 > > Abstract: > This memo offers a framework for a protocol that enables devices in > a > telepresence conference to interoperate by specif;ying the > relationships between multiple RTP streams. > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Wed Jul 27 05:12:58 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37A621F8AD9 for ; Wed, 27 Jul 2011 05:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.495 X-Spam-Level: X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=-0.896, 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 CNR+bhF3N5sD for ; Wed, 27 Jul 2011 05:12:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9853821F86A4 for ; Wed, 27 Jul 2011 05:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=8759; q=dns/txt; s=iport; t=1311768777; x=1312978377; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=oC8g6dk4dDb3YDJmt6Q1RcbUru2AKryrUf1FCMFaJcQ=; b=YfrrNM9vcO3ci1WyH2nZi+67m1OLZMmAMuzdvYlECOSqJRIgIqi/d1+Q 62WOTUefccM81aSKASndyrNZ+bbjPXoC9P5dwRgv+zB6jtm4NQLJz6Qw+ 5OI5OrSMSQBy59iJkHu0UAXLnau7e9Cg0YLxZq9paSiR0Bpnf7bn9Nd5r M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAEQAME6rRDoJ/2dsb2JhbAA1AQEBAQMBAQERASEKNAYGEQUCARoEAQEBCgYjAQYBExgjDggBAQUBFgwUB5dQj0d3iQCheJ5hhWFfBIdXkC6Lcg X-IronPort-AV: E=Sophos;i="4.67,276,1309737600"; d="scan'208";a="6929315" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-4.cisco.com with ESMTP; 27 Jul 2011 12:12:56 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6RCCuev016740; Wed, 27 Jul 2011 12:12:56 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Jul 2011 05:12:56 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 05:12:47 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0514DF21@xmb-sjc-221.amer.cisco.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AE802559@CRPMBOXPRD01.polycom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: framework - was RE: [clue] Comment on rendering slides Thread-Index: AcxLqbB+ZnGIXe7DQw2JUp54PzZQPQAMRgKAAA1x8YA= References: <4E2EDEB7.1080708@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AE802559@CRPMBOXPRD01.polycom.com> From: "Allyn Romanow (allyn)" To: "Duckworth, Mark" , X-OriginalArrivalTime: 27 Jul 2011 12:12:56.0339 (UTC) FILETIME=[84A7CE30:01CC4C56] Subject: [clue] framework - was RE: Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 12:12:58 -0000 Just to add a bit to Mark's response. I agree that it's not clear whether the framework should/could be mapped to offer/answer. It seems like a good idea to develop this solution in somewhat discrete stages, first specifying what we want to do, and then considering the best (or possible) mechanisms, such as SDP. As for the receiver starting the dialogue with the provider by telling it information about itself to inform the advertisements sent by the sender, the framework specifies this as optional.=20 The current draft of the framework is specifically aimed at just the basic ideas and deliberately leaves details for the next version, even though they are of course crucial. It seems best if we could agree on basic design decisions, and then fill them out- rather than presenting everything at once - it seemed like we might get bogged down in details and not focus on the basic ideas. Allyn > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Duckworth, Mark > Sent: Tuesday, July 26, 2011 2:43 PM > To: clue@ietf.org > Subject: Re: [clue] Comment on rendering slides >=20 > I think we are really talking about draft-romanow-clue-framework-00 and > not the rendering slides, but I left the subject line the same :) >=20 > Yes, the framework allows both sides of an exchange to act as both a > Media Provider (sender) and a Media Consumer (receiver), with a > separate dialog for each direction, so the resulting media flows can be > asymmetric. >=20 > As for the receiver indicating preferences up front, yes, it is partly > there in the document, that is what the "hints" mentioned in section 7 > are for. The concept is there, but exactly what to do with it is not > yet fleshed out. >=20 > And for the receiver indicating what it wants the streams to contain, > that is partly there too if the sender advertises choices that have > different attributes. So for example a receiver could choose between a > "composed" video stream and a "switched" video stream. Exactly how the > composition and switching is done is not specified in the framework. > If there is a need to exchange this information, perhaps it could be > added, but I don't think the use case document has any cases yet where > this would be required, and I didn't see it in the requirements > document either. >=20 > The use case document also mentions ability to choose media from a > specific source, for example I might want to always see a particular > person in the conference even though that person rarely speaks. This > type of source selection is not yet covered in the framework. For > other types of source selection, I think we need more use cases to > inform requirements. >=20 > I'm not sure either if this framework can or should be mapped on to SDP > offer/answer. That needs further discussion. >=20 > Mark Duckworth >=20 >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Paul Kyzivat > > Sent: Tuesday, July 26, 2011 11:35 AM > > To: clue@ietf.org > > Subject: Re: [clue] Comment on rendering slides > > > > (as individual) > > > > I largely agree with Charles. > > > > ISTM that what this is developing into is a more extensive > negotiation > > than is possible with one round of o/a exchange. > > > > Conceivably this could be done using multiple o/a exchanges, but that > > may not be the best way. > > > > It seems to me that when a box advertises what it can provide, it > > probably doesn't want to be required to have all of those already > > available. IOW, the advertisement is like a menu from which the > > recipient can order, rather than a buffet from which the recipient > can > > take things. (An SDP offer is a buffet.) The sender can then defer > > cooking the item until it knows it has an order. > > > > The other issue is whether the sender can realistically enumerate the > > entire menu. Perhaps there are too many variations possible. In that > > case the "customer" may want to request something that is not on the > > menu. Maybe that then gets added to the menu, and maybe not. > > > > Whether we need to go that way may depend on the mechanism used to > > deliver the advertisement/menu. If its done via SDP then the size of > > the > > menu is probably quite limited. If it is done some other way, then > > maybe > > not. > > > > Thanks, > > Paul > > > > On 7/26/11 10:51 AM, Charles Eckel (eckelcu) wrote: > > > I would prefer to continue to use the existing SDP mechanism to > > describe > > > what an endpoint is capable of receiving. I think the existing > > framework > > > draft provides a mechanism for a sender to indicate what it can > send, > > > and for a receiver to select which of those it wants to receive. > > > As for asymmetry, I read the framework as allowing each side to act > > as a > > > sender and a receiver, facilitating asymmetry. If others think this > > is > > > not the case, then I agree with John that we need to clarify that. > > > > > > What I think is missing is: > > > - a mechanism for a receiver to indicate a preference for, or a > > request > > > for, a specific rendering, or layout, or format (i.e. not just that > I > > > want one H.264 video stream and one G.722 audio stream, but what I > > want > > > each of those to contain). > > > > > > The main benefit of doing this is that it might allow a sender to > > tailor > > > its description of what it can send to include options that the > > receiver > > > requested, as opposed to the sender trying to list every single > > possible > > > combination it can imagine. > > > There are many ways to do this, and I do not want to get into the > > > details here, but if we agree that we need a mechanism for a > receiver > > to > > > advertise its preference or request something specific from the > > sender > > > along these line, then I think we can cover Christer's rendering > use > > > cases as well as some of the use cases I mentioned previously > > regarding > > > composition. If we list out the use cases, we can make sure this > > > mechanism is sufficient to address all of them. > > > > > > Cheers, > > > Charles > > > > > >> -----Original Message----- > > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > > > Of Elwell, John > > >> Sent: Tuesday, July 26, 2011 8:33 AM > > >> To: clue@ietf.org > > >> Subject: [clue] Comment on rendering slides > > >> > > >> Based on this morning's discussion, I have a problem with the > > proposal > > > on the last slide: > > >> > > >> "REQ-x: It MUST be possible for a client to indicate, per > media > > > stream, supported rendering > > >> type(s). > > >> REQ-y: It MUST be possible to inform a client, per media > > > stream, the rendering type(s) applied to > > >> the stream. " > > >> > > >> I believe this is a more asymmetric problem, and perhaps needs to > be > > > expressed in terms of: > > >> "REQ-x: It MUST be possible for a client to indicate, per > media > > > stream, rendering type(s) it is > > >> able to transmit. > > >> > > >> REQ-y: It MUST be possible to inform a client, per media > > > stream, the rendering type(s) that can > > >> be received." > > >> > > >> (where the media types to be received would be selected from those > > > able to be transmitted by the peer) > > >> > > >> Notwithstanding, of course, that we need to explore more use cases > > to > > > see whether this really fits. > > >> > > >> John > > >> > > >> John Elwell > > >> Tel: +44 1908 817801 (office and mobile) > > >> Email: john.elwell@siemens-enterprise.com > > >> http://www.siemens-enterprise.com/uk/ > > >> > > >> Siemens Enterprise Communications Limited. > > >> Registered office: Brickhill Street, Willen Lake, Milton Keynes, > > MK15 > > > 0DJ. > > >> Registered No: 5903714, England. > > >> > > >> Siemens Enterprise Communications Limited is a Trademark Licensee > of > > > Siemens AG. > > >> > > >> > > >> _______________________________________________ > > >> clue mailing list > > >> clue@ietf.org > > >> https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Jul 27 06:26:07 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A94D21F858C for ; Wed, 27 Jul 2011 06:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 21XbqMQSgRv6 for ; Wed, 27 Jul 2011 06:26:06 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4436B21F8557 for ; Wed, 27 Jul 2011 06:26:06 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta06.westchester.pa.mail.comcast.net with comcast id D1A41h0041ap0As561S6jZ; Wed, 27 Jul 2011 13:26:06 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta22.westchester.pa.mail.comcast.net with comcast id D1Rc1h00B5EhBnE3i1RkKz; Wed, 27 Jul 2011 13:25:56 +0000 Message-ID: <4E3011CE.3070808@alum.mit.edu> Date: Wed, 27 Jul 2011 09:25:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: clue@ietf.org References: <4E2EDEB7.1080708@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AE802559@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AE802559@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 13:26:07 -0000 On 7/26/11 5:43 PM, Duckworth, Mark wrote: > I think we are really talking about draft-romanow-clue-framework-00 and not the rendering slides, but I left the subject line the same :) > > Yes, the framework allows both sides of an exchange to act as both a Media Provider (sender) and a Media Consumer (receiver), with a separate dialog for each direction, so the resulting media flows can be asymmetric. We aren't really discussing mechanism in detail yet, so this is probably premature. But do you *really* mean a separate *dialog* in each direction??? That seems very weird. I can understand how there might be a separate m-line for each direction, which allows the properties to differ radically. > As for the receiver indicating preferences up front, yes, it is partly there in the document, that is what the "hints" mentioned in section 7 are for. The concept is there, but exactly what to do with it is not yet fleshed out. OK. That wasn't entirely obvious, though that is what I had inferred. > And for the receiver indicating what it wants the streams to contain, that is partly there too if the sender advertises choices that have different attributes. So for example a receiver could choose between a "composed" video stream and a "switched" video stream. Exactly how the composition and switching is done is not specified in the framework. If there is a need to exchange this information, perhaps it could be added, but I don't think the use case document has any cases yet where this would be required, and I didn't see it in the requirements document either. > > The use case document also mentions ability to choose media from a specific source, for example I might want to always see a particular person in the conference even though that person rarely speaks. This type of source selection is not yet covered in the framework. For other types of source selection, I think we need more use cases to inform requirements. > > I'm not sure either if this framework can or should be mapped on to SDP offer/answer. That needs further discussion. I am in agreement with John here. With o/a, one side or the other is "first". For both sides to indicate a preference, then receive an advertisement, then make a selection, two or even three o/a cycles may be needed. But that is doable. Thanks, Paul > Mark Duckworth > > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Tuesday, July 26, 2011 11:35 AM >> To: clue@ietf.org >> Subject: Re: [clue] Comment on rendering slides >> >> (as individual) >> >> I largely agree with Charles. >> >> ISTM that what this is developing into is a more extensive negotiation >> than is possible with one round of o/a exchange. >> >> Conceivably this could be done using multiple o/a exchanges, but that >> may not be the best way. >> >> It seems to me that when a box advertises what it can provide, it >> probably doesn't want to be required to have all of those already >> available. IOW, the advertisement is like a menu from which the >> recipient can order, rather than a buffet from which the recipient can >> take things. (An SDP offer is a buffet.) The sender can then defer >> cooking the item until it knows it has an order. >> >> The other issue is whether the sender can realistically enumerate the >> entire menu. Perhaps there are too many variations possible. In that >> case the "customer" may want to request something that is not on the >> menu. Maybe that then gets added to the menu, and maybe not. >> >> Whether we need to go that way may depend on the mechanism used to >> deliver the advertisement/menu. If its done via SDP then the size of >> the >> menu is probably quite limited. If it is done some other way, then >> maybe >> not. >> >> Thanks, >> Paul >> >> On 7/26/11 10:51 AM, Charles Eckel (eckelcu) wrote: >>> I would prefer to continue to use the existing SDP mechanism to >> describe >>> what an endpoint is capable of receiving. I think the existing >> framework >>> draft provides a mechanism for a sender to indicate what it can send, >>> and for a receiver to select which of those it wants to receive. >>> As for asymmetry, I read the framework as allowing each side to act >> as a >>> sender and a receiver, facilitating asymmetry. If others think this >> is >>> not the case, then I agree with John that we need to clarify that. >>> >>> What I think is missing is: >>> - a mechanism for a receiver to indicate a preference for, or a >> request >>> for, a specific rendering, or layout, or format (i.e. not just that I >>> want one H.264 video stream and one G.722 audio stream, but what I >> want >>> each of those to contain). >>> >>> The main benefit of doing this is that it might allow a sender to >> tailor >>> its description of what it can send to include options that the >> receiver >>> requested, as opposed to the sender trying to list every single >> possible >>> combination it can imagine. >>> There are many ways to do this, and I do not want to get into the >>> details here, but if we agree that we need a mechanism for a receiver >> to >>> advertise its preference or request something specific from the >> sender >>> along these line, then I think we can cover Christer's rendering use >>> cases as well as some of the use cases I mentioned previously >> regarding >>> composition. If we list out the use cases, we can make sure this >>> mechanism is sufficient to address all of them. >>> >>> Cheers, >>> Charles >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >>> Of Elwell, John >>>> Sent: Tuesday, July 26, 2011 8:33 AM >>>> To: clue@ietf.org >>>> Subject: [clue] Comment on rendering slides >>>> >>>> Based on this morning's discussion, I have a problem with the >> proposal >>> on the last slide: >>>> >>>> "REQ-x: It MUST be possible for a client to indicate, per media >>> stream, supported rendering >>>> type(s). >>>> REQ-y: It MUST be possible to inform a client, per media >>> stream, the rendering type(s) applied to >>>> the stream. " >>>> >>>> I believe this is a more asymmetric problem, and perhaps needs to be >>> expressed in terms of: >>>> "REQ-x: It MUST be possible for a client to indicate, per media >>> stream, rendering type(s) it is >>>> able to transmit. >>>> >>>> REQ-y: It MUST be possible to inform a client, per media >>> stream, the rendering type(s) that can >>>> be received." >>>> >>>> (where the media types to be received would be selected from those >>> able to be transmitted by the peer) >>>> >>>> Notwithstanding, of course, that we need to explore more use cases >> to >>> see whether this really fits. >>>> >>>> John >>>> >>>> John Elwell >>>> Tel: +44 1908 817801 (office and mobile) >>>> Email: john.elwell@siemens-enterprise.com >>>> http://www.siemens-enterprise.com/uk/ >>>> >>>> Siemens Enterprise Communications Limited. >>>> Registered office: Brickhill Street, Willen Lake, Milton Keynes, >> MK15 >>> 0DJ. >>>> Registered No: 5903714, England. >>>> >>>> Siemens Enterprise Communications Limited is a Trademark Licensee of >>> Siemens AG. >>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Mark.Duckworth@polycom.com Wed Jul 27 08:05:57 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0187F21F8B8D for ; Wed, 27 Jul 2011 08:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, 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 0KskYY5eDE1r for ; Wed, 27 Jul 2011 08:05:55 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 96AD421F851A for ; Wed, 27 Jul 2011 08:05:53 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Wed, 27 Jul 2011 08:05:52 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 27 Jul 2011 08:05:49 -0700 Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-framework-00.txt Thread-Index: Acw5yGOQjEx2NapwSjuqXrun//JqxgAAArYABJDNY4AAFTKqEA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE80277A@CRPMBOXPRD01.polycom.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC04D45819@xmb-sjc-221.amer.cisco.com> <003a01cc4c12$59904090$0cb0c1b0$%roni@huawei.com> In-Reply-To: <003a01cc4c12$59904090$0cb0c1b0$%roni@huawei.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] FW: New Version Notification for draft-romanow-clue-framework-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 15:05:57 -0000 Some answers inline... > -----Original Message----- > From: Roni Even >=20 > Sent: Wednesday, July 27, 2011 12:05 AM >=20 > Hi, > Found some time to review the draft, it is a good start but I think it ne= eds > more work. Some comments ( the one from 5 to 8 may look similar but they = are > all about the relation between sender and receiver and captures sets as > appear in the draft) >=20 > 1. This is the major one. I saw "VC0- (the left camera stream), encoding > group:EG0, attributes:purpose=3Dmain;auto-switched:no" and "VC5- (the zoo= med > out view of all people in the room ), encoding group:EG1, attributes: > purpose=3Dmain;auto-switched:no". How do you encode in the messge (the le= ft > camera stream) or (the zoomed out view of all people in the room). How do > you define such information. Without this definition the rest of the synt= ax > is not enough to understand the offers. Those notes "(the left camera stream)" and "(the zoomed out view of all peo= ple in the room)" are just explanatory notes, not necessarily explicitly en= coded. The left/center/right information is conveyed in Capture Set #1 by = the order of VC0, VC1, VC2 in the first row. The "zoomed out view" could b= e implied by the video scale attribute and absence of the switched attribut= e, but that is not shown in this example. The intent is to provide enough = information so the Media Consumer can make a good choice, but not necessari= ly all possible detail that isn't really required. =20 > 2. in the introduction section it says that this is the basic approach an= d > mechanism and that next versions will address more use cases. What is nex= t > version, are we going to publish only basic mechanism according to this > draft and have the other in a different draft or is this going to be in n= ew > version of the current draft-romanow-clue-framework future versions of current draft. > 3. In the definition section there is no definition to media stream > that is used in it. Stream is defined as "RTP stream as in RFC3550", which itself is not a prec= ise definition. Do you have a suggestion for a better definition? > 4. The capture set definition "includes Media Captures that all represent > some aspect of the same Capture Scene. The items (rows) in a Capture Set > represent different alternatives for representing the same Capture Scene= .". > Reading the description I assume that a capture set includes the layout f= rom > the sender perspective and it provide information about the layout or > geometry as well as the content of each capture device. Is this true It includes the spatial relationship of the media captures, which is the or= dering from left to right in which they should be rendered. And the "compo= sed" attribute gives a hint about video layout within a video capture. We = didn't see that more detail about layout or geometry was necessary. > 5. If 4 is correct than in section 6.3 "A media receiver could choose on= e > row of each media type (e.g., audio and video) from a capture set. For > example a three stream receiver could choose the first video row plus th= e > audio row, while a single stream receiver could choose the second or thi= rd > video row plus the audio row." I was wondering how can a receiver select > just one capture stream from the capture set if not specified by itself, > like just the left camera or from the example in section 7.1 "{VC0, VC1, > VC2}" just VC0. Yes, the intent is to allow a receiver to select a subset of media captures= from a particular row, it doesn't have to ask for the entire row. The fra= mework doesn't go into detail about how to do this selection, but I think i= t is basically just a list of media captures. =20 > 6. The text in section 6.3 "An MCU receiver might choose to receive multi= ple > rows". I thought that rows are physical simultaneity so cannot be sent > at the same time. No, the simultaneous transmission sets are separate from the capture sets. = The simultaneous information may or may not permit multiple capture set ro= ws to be used simultaneously. > 7. My understanding from section 4 and 5 "The protocol resulting from the > framework will be declarative rather than negotiative." is that the sende= r > sends the list of capture set and may send anything from it. I do not se= e > how the receiver selects the capture set it wants to receive now or a sub= set > from it (my question 5). Yet section 6.3 says that the receiver can chose= a > capture set from all the offered ones. So is this a negotiation? > Defiantly if it can ask for a capture set that will have only a subset of= the > captures in a row. Maybe the framework isn't clear on how the receiver selects the media captu= res. I think it should simply be just a list of media captures, selected f= rom the Media Producer's capture sets, that the Media Consumer sends to the= Media Producer. I'm not sure what is the importance of calling this "declarative" or "negot= iative", it doesn't matter to me. > 8. More on this, in section 7.1 "{VC0, VC3, VC2}" is says "both VC0 and > VC2 are redundant if VC3 is included". What does redundant mean, that VC = and > VC2 are not sent or that the receiver can say it wants to receive {VC3} o= r > {VC0, VC3) This example should be improved by adding the capture set (remember this is= different than the simultaneous transmission set), which would show VC3 by= itself in a capture set row. So since VC3 is all by itself in a row, it r= epresents the entire capture scene, so other VCs for the same scene would b= e somewhat redundant, but not necessarily disallowed. > 9. In A.5 how is this parameter used? One example for usage of the video scale parameter is for a sender to indic= ate by this attribute that the image in the video is 1 meter wide. If the = receiver has a display that is 2 meters wide, maybe the receiver would like= to scale down the video during rendering in order to display it at the cor= rect size for the application. Regards, Mark Duckworth > Regards > Roni >=20 > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > > Allyn Romanow (allyn) > > Sent: Monday, July 04, 2011 12:32 AM > > To: clue@ietf.org > > Subject: [clue] FW: New Version Notification for draft-romanow-clue- > > framework-00.txt > > > > Folks, > > > > A first draft for the framework has just been posted. > > > > Best regards, > > Allyn > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Sunday, July 03, 2011 2:30 PM > > To: Allyn Romanow (allyn) > > Cc: mark.duckworth@polycom.com; Allyn Romanow (allyn); Andrew > Pepperell > > (apeppere); mark.gorzynski@hp.com; bbaldino@polycom.com > > Subject: New Version Notification for draft-romanow-clue-framework- > > 00.txt > > > > A new version of I-D, draft-romanow-clue-framework-00.txt has been > > successfully submitted by Allyn Romanow and posted to the IETF > > repository. > > > > Filename: draft-romanow-clue-framework > > Revision: 00 > > Title: Framework for Telepresence Multi-Streams > > Creation date: 2011-07-03 > > WG ID: Individual Submission > > Number of pages: 31 > > > > Abstract: > > This memo offers a framework for a protocol that enables devices > in > > a > > telepresence conference to interoperate by specif;ying the > > relationships between multiple RTP streams. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Jul 27 14:14:40 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF90921F8AF8 for ; Wed, 27 Jul 2011 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 hmw+GwVnO08t for ; Wed, 27 Jul 2011 14:14:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id ED5CA21F8ADE for ; Wed, 27 Jul 2011 14:14:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-fe-4e307fbd0d6e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 99.F6.09774.DBF703E4; Wed, 27 Jul 2011 23:14:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 27 Jul 2011 23:14:37 +0200 From: Christer Holmberg To: "Elwell, John" , "Charles Eckel (eckelcu)" , "clue@ietf.org" Date: Wed, 27 Jul 2011 23:12:03 +0200 Thread-Topic: [clue] Comment on rendering slides Thread-Index: AcxLkCH6LYKpHXGfR12MLIQ5EVqQGgAEVyNgAAEW70AAPv6n3g== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FE3@ESESSCMS0356.eemea.ericsson.se> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 21:14:40 -0000 Hi, Based on the very good discussions and feedback on tuesday morning, I am up= dating the slides, so that they talk about saying what one can send, and sa= ying what one can receive. Whether we eventually will use SDP for this I think is outside the scope as= far as the requirements are concerned. Therefor, in order to avoid confusi= on, I have removed all text talking about "offer" and "answer". Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Elwell, Jo= hn [john.elwell@siemens-enterprise.com] Sent: Tuesday, July 26, 2011 6:23 PM To: Charles Eckel (eckelcu); clue@ietf.org Subject: Re: [clue] Comment on rendering slides Yes, I think the framework does provide for asymmetry, so perhaps the need = to refine these requirements is moot. As to whether the current framework i= s mappable onto offer-answer, I am not sure. Probably by using >1 offer-ans= wer cycles it could be done. The question of whether we need to start with the receiver saying what it c= an receive (and the sender choosing what to select what to send on that bas= is) or start with the sender saying what it can send (and the receiver choo= sing what it wants to receive from that list) is a valid question and I am = not sure I understand what the right answer is. For example, a receiver wit= h a large screen perhaps has unlimited capabilities as to what it can displ= ay on that screen, so negotiation really needs to start with the sender say= ing what it can send and the receiver making a selection. On the other hand= , a receiver with a single speaker might want to start by saying it can rec= eive a single audio stream, and the sender selects the most appropriate str= eam to send out of those it is able to capture. Perhaps the framework has t= he necessary flexibility - I am not sure. John > -----Original Message----- > From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] > Sent: 26 July 2011 15:52 > To: Elwell, John; clue@ietf.org > Subject: RE: [clue] Comment on rendering slides > > I would prefer to continue to use the existing SDP mechanism > to describe > what an endpoint is capable of receiving. I think the > existing framework > draft provides a mechanism for a sender to indicate what it can send, > and for a receiver to select which of those it wants to receive. > As for asymmetry, I read the framework as allowing each side > to act as a > sender and a receiver, facilitating asymmetry. If others think this is > not the case, then I agree with John that we need to clarify that. > > What I think is missing is: > - a mechanism for a receiver to indicate a preference for, or > a request > for, a specific rendering, or layout, or format (i.e. not just that I > want one H.264 video stream and one G.722 audio stream, but > what I want > each of those to contain). > > The main benefit of doing this is that it might allow a > sender to tailor > its description of what it can send to include options that > the receiver > requested, as opposed to the sender trying to list every > single possible > combination it can imagine. > There are many ways to do this, and I do not want to get into the > details here, but if we agree that we need a mechanism for a > receiver to > advertise its preference or request something specific from the sender > along these line, then I think we can cover Christer's rendering use > cases as well as some of the use cases I mentioned previously > regarding > composition. If we list out the use cases, we can make sure this > mechanism is sufficient to address all of them. > > Cheers, > Charles > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Elwell, John > > Sent: Tuesday, July 26, 2011 8:33 AM > > To: clue@ietf.org > > Subject: [clue] Comment on rendering slides > > > > Based on this morning's discussion, I have a problem with > the proposal > on the last slide: > > > > "REQ-x: It MUST be possible for a client to indicate, per media > stream, supported rendering > > type(s). > > REQ-y: It MUST be possible to inform a client, per media > stream, the rendering type(s) applied to > > the stream. " > > > > I believe this is a more asymmetric problem, and perhaps needs to be > expressed in terms of: > > "REQ-x: It MUST be possible for a client to indicate, per media > stream, rendering type(s) it is > > able to transmit. > > > > REQ-y: It MUST be possible to inform a client, per media > stream, the rendering type(s) that can > > be received." > > > > (where the media types to be received would be selected from those > able to be transmitted by the peer) > > > > Notwithstanding, of course, that we need to explore more > use cases to > see whether this really fits. > > > > John > > > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > > > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton > Keynes, MK15 > 0DJ. > > Registered No: 5903714, England. > > > > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From christer.holmberg@ericsson.com Wed Jul 27 14:19:19 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A5C21F8B42 for ; Wed, 27 Jul 2011 14:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 5GU9RdTsBLCW for ; Wed, 27 Jul 2011 14:19:19 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C834121F8B26 for ; Wed, 27 Jul 2011 14:19:18 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-86-4e3080d5e5ec Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 74.C7.20773.5D0803E4; Wed, 27 Jul 2011 23:19:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 27 Jul 2011 23:19:17 +0200 From: Christer Holmberg To: "Elwell, John" , "clue@ietf.org" Date: Wed, 27 Jul 2011 23:16:14 +0200 Thread-Topic: Comment on rendering slides Thread-Index: AcxLkCH6LYKpHXGfR12MLIQ5EVqQGgBEkj1r Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FE4@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 21:19:19 -0000 Hi, >I believe this is a more asymmetric problem, and perhaps needs to be expre= ssed in terms of: >"REQ-x: It MUST be possible for a client to indicate, per media stream, re= ndering type(s) it is able to >transmit. > >REQ-y: It MUST be possible to inform a client, per media stream, the rend= ering type(s) that can be >received." > >(where the media types to be received would be selected from those able to= be transmitted by the peer) Yes. And, it must also be indicated which types have actually been selected= . That can be done e.g. by the sender first "advertising" what it is able to = send, and the receiver then "selects" what it wants to receive. Regards, Christer= From Even.roni@huawei.com Wed Jul 27 15:01:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80A311E80C3 for ; Wed, 27 Jul 2011 15:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 qX+6IxF9qe+2 for ; Wed, 27 Jul 2011 15:01:59 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1F45E11E80B6 for ; Wed, 27 Jul 2011 15:01:59 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000EN0IJ8QE@szxga05-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 06:01:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0005HSIJ873@szxga05-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 06:01:56 +0800 (CST) Received: from windows8d787f9 (dhcp-438f.meeting.ietf.org [130.129.67.143]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP0006EBIJ5JW@szxml11-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 06:01:56 +0800 (CST) Date: Thu, 28 Jul 2011 00:59:13 +0300 From: Roni Even To: clue@ietf.org Message-id: <00e201cc4ca8$6e539590$4afac0b0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gKdFK3cwPy9imKWn7mTRww)" Content-language: en-us Thread-index: AcxMqGvImh9NvgMbTN6/eAlpxjefCA== Subject: [clue] framework - capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2011 22:01:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gKdFK3cwPy9imKWn7mTRww) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, The capture set example has (VC4 - zoomed out view of all people in the room.). Now is there a way to differentiate between zoom out view and composite view of all cameras to the 3 to 1 screen use case? How do you see the extension to support multi view is there is no way to describe the camera view port explicitly? Roni --Boundary_(ID_gKdFK3cwPy9imKWn7mTRww) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

The capture set example has (VC4 - zoomed out view of all people in the room.). Now is there a way to differentiate between zoom out view and composite view of all cameras to the 3 to 1 screen use case?

 

How do you see the extension to support multi view is there is no way to describe the camera view port explicitly?

 

Roni

 

--Boundary_(ID_gKdFK3cwPy9imKWn7mTRww)-- From Even.roni@huawei.com Wed Jul 27 15:11:03 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDF121F889A for ; Wed, 27 Jul 2011 15:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.523 X-Spam-Level: X-Spam-Status: No, score=-106.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ro3onYsBbfGF for ; Wed, 27 Jul 2011 15:11:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4B09921F88B7 for ; Wed, 27 Jul 2011 15:10:43 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0009DDIXCI9@szxga03-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 06:10:24 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0001XJIXCSV@szxga03-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 06:10:24 +0800 (CST) Received: from windows8d787f9 (dhcp-438f.meeting.ietf.org [130.129.67.143]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP0006NLIX8JW@szxml11-in.huawei.com>; Thu, 28 Jul 2011 06:10:24 +0800 (CST) Date: Thu, 28 Jul 2011 01:07:41 +0300 From: Roni Even In-reply-to: To: stephane.cazeaux@orange-ftgroup.com, clue@ietf.org Message-id: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_abxuMZ3rHOfHvjypRjgA1A)" Content-language: en-us Thread-index: AcxHlL8VW+C7KhbYQU2HJX/U8MKZpAFFKK/A References: Subject: Re: [clue] Comment on the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 22:11:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_abxuMZ3rHOfHvjypRjgA1A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Stephane, Is there a standard protocol that is used for conveying this information, is it RTP based. To me this is a separate application that can be integrated in the application level and not as part of the multistream. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of stephane.cazeaux@orange-ftgroup.com Sent: Thursday, July 21, 2011 2:33 PM To: clue@ietf.org Subject: [clue] Comment on the presentation use case Hi, The presentation use case as described in the use-cases document is based on the assumption that the presentation stream relies on a video stream, and is limited to usage of presentation video streams. But we could also consider collaborative use cases, meaningful for telepresence, which are not covered by the existing text. I propose to complete the existing text as follows: " Furthermore, although most today's systems use video streams for presentations, there are use cases where this is not suitable. For example: - The professor which shares an electronic whiteboard (could be a whiteboard application on a PC, with screen capture of the PC) where all students can participate. Students will take control of the shared whiteboard in turns. - In a multipoint meeting, a shared document can be kept always visible in a screen, while other documents are presented on other screens (with possible in turns presentation). For instance, for the purpose of shared design document, notes taking, polls, etc. A shared document implies that all participants can modify it in turns. " Stephane. --Boundary_(ID_abxuMZ3rHOfHvjypRjgA1A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Stephane,

Is there a standard protocol that is used for conveying this information, is it RTP based.

To me this is a separate application that can be integrated in the application level and not as part of the multistream.

 

Roni

 

clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of stephane.cazeaux@orange-ftgroup.com
Sent: Thursday, July 21, 2011 2:33 PM
To: clue@ietf.org
Subject: [clue] Comment on the presentation use case

 

Hi,

 

The presentation use case as described in the use-cases document is based on the assumption that the presentation stream relies on a video stream, and is limited to usage of presentation video streams. But we could also consider collaborative use cases, meaningful for telepresence, which are not covered by the existing text.

I propose to complete the existing text as follows:

 

Furthermore, although most today's systems use video streams for presentations, there are use cases where this is not suitable. For example:

- The professor which shares an electronic whiteboard (could be a whiteboard application on a PC, with screen capture of the PC) where all students can participate. Students will take control of the shared whiteboard in turns.

- In a multipoint meeting, a shared document can be kept always visible in a screen, while other documents are presented on other screens (with possible in turns presentation). For instance, for the purpose of shared design document, notes taking, polls, etc. A shared document implies that all participants can modify it in turns.

“

 

 

St ephane. v> --Boundary_(ID_abxuMZ3rHOfHvjypRjgA1A)-- From john.elwell@siemens-enterprise.com Wed Jul 27 15:13:22 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1D711E8177 for ; Wed, 27 Jul 2011 15:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.643 X-Spam-Level: X-Spam-Status: No, score=-103.643 tagged_above=-999 required=5 tests=[AWL=-1.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 M1G3+OBkTJg0 for ; Wed, 27 Jul 2011 15:13:22 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id EB68E11E816F for ; Wed, 27 Jul 2011 15:13:21 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 2CF0A23F0577 for ; Thu, 28 Jul 2011 00:13:21 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 28 Jul 2011 00:13:21 +0200 From: "Elwell, John" To: "clue@ietf.org" Date: Thu, 28 Jul 2011 00:13:19 +0200 Thread-Topic: Comment on framework - who gives the hint Thread-Index: AcxMqmQSQWS7gQMfRVmOILKsMyyz8Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Comment on framework - who gives the hint X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 22:13:22 -0000 The framework is based on the following general principle: - receiver optionally sends hints as to what it would like to receive; - sender indicates what it can send; - receives selects what it will receive. Another possibility would be: - transmitter optionally sends hints as to what it can send; - receiver indicates what it can receive; - transmitter selects what it will send. I don't have any opinion as to which is the better - in fact I tend to lean= towards the first, but I can't give a reason. But it would be good to know= if there are specific reasons for going with the first rather than the sec= ond. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. = From Even.roni@huawei.com Wed Jul 27 15:20:50 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C9A11E8180 for ; Wed, 27 Jul 2011 15:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 guMCzVpL9S53 for ; Wed, 27 Jul 2011 15:20:49 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6459211E8097 for ; Wed, 27 Jul 2011 15:20:48 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000IWUJENLA@szxga03-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 06:20:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0004Q8JENKO@szxga03-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 06:20:47 +0800 (CST) Received: from windows8d787f9 (dhcp-438f.meeting.ietf.org [130.129.67.143]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP000DAPJEKAY@szxml12-in.huawei.com>; Thu, 28 Jul 2011 06:20:47 +0800 (CST) Date: Thu, 28 Jul 2011 01:18:05 +0300 From: Roni Even In-reply-to: To: "'Elwell, John'" , clue@ietf.org Message-id: <00f701cc4cab$10b02680$32107380$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxMqmQSQWS7gQMfRVmOILKsMyyz8QAAEZZA References: Subject: Re: [clue] Comment on framework - who gives the hint X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 22:20:50 -0000 John, I think that this will enable the sender to send a smaller subset if its options. For example if the receiver can hint that it has one monitor the sender can indicate just the options for sending a proposal for one screen. It is not perfect since maybe the receiver can receive three streams and compose them so it depends on how the receivers hints will be flexible. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Thursday, July 28, 2011 1:13 AM > To: clue@ietf.org > Subject: [clue] Comment on framework - who gives the hint > > The framework is based on the following general principle: > - receiver optionally sends hints as to what it would like to receive; > - sender indicates what it can send; > - receives selects what it will receive. > > Another possibility would be: > - transmitter optionally sends hints as to what it can send; > - receiver indicates what it can receive; > - transmitter selects what it will send. > > I don't have any opinion as to which is the better - in fact I tend to > lean towards the first, but I can't give a reason. But it would be good > to know if there are specific reasons for going with the first rather > than the second. > > John > > > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Wed Jul 27 15:29:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892F211E816C for ; Wed, 27 Jul 2011 15:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOY4Eip4Im76 for ; Wed, 27 Jul 2011 15:29:43 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id DFCF811E8097 for ; Wed, 27 Jul 2011 15:29:42 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id DASV1h0030mv7h053AVj8i; Wed, 27 Jul 2011 22:29:43 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta11.westchester.pa.mail.comcast.net with comcast id DAVA1h00J5EhBnE3XAVLcu; Wed, 27 Jul 2011 22:29:26 +0000 Message-ID: <4E309135.7070408@alum.mit.edu> Date: Wed, 27 Jul 2011 18:29:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: clue@ietf.org References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> In-Reply-To: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Comment on the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 22:29:43 -0000 On 7/27/11 6:07 PM, Roni Even wrote: > Hi Stephane, > > Is there a standard protocol that is used for conveying this > information, is it RTP based. AFAIK this is often http. (E.g. webex) > To me this is a separate application that can be integrated in the > application level and not as part of the multistream. I guess this depends on whether the support for it is integrated into the "room", or is just incidental equipment brought by the users, not formally related to the telepresence session. Thanks, Paul (speaking as an individual) > Roni > > *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of > *stephane.cazeaux@orange-ftgroup.com > *Sent:* Thursday, July 21, 2011 2:33 PM > *To:* clue@ietf.org > *Subject:* [clue] Comment on the presentation use case* > > ** > > *Hi,* > > ** > > *The presentation use case as described in the use-cases document is > based on the assumption that the presentation stream relies on a video > stream, and is limited to usage of presentation video streams. But we > could also consider collaborative use cases, meaningful for > telepresence, which are not covered by the existing text.* > > *I propose to complete the existing text as follows:* > > ** > > *Furthermore, although most today's systems use video streams for > presentations, there are use cases where this is not suitable. For example:* > > *- The professor which shares an electronic whiteboard (could be a > whiteboard application on a PC, with screen capture of the PC) where all > students can participate. Students will take control of the shared > whiteboard in turns.* > > *- In a multipoint meeting, a shared document can be kept always visible > in a screen, while other documents are presented on other screens (with > possible in turns presentation). For instance, for the purpose of shared > design document, notes taking, polls, etc. A shared document implies > that all participants can modify it in turns.* > > *“* > > ** > > ** > > *St ephane. v> > * > > * > * > > *_______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > * From pkyzivat@alum.mit.edu Wed Jul 27 15:56:28 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF7311E80BA for ; Wed, 27 Jul 2011 15:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 RcrvbTeQUo9w for ; Wed, 27 Jul 2011 15:56:28 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3F19311E8084 for ; Wed, 27 Jul 2011 15:56:28 -0700 (PDT) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta02.emeryville.ca.mail.comcast.net with comcast id D9wo1h0061smiN4A2AwQFY; Wed, 27 Jul 2011 22:56:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([70.25.120.2]) by omta20.emeryville.ca.mail.comcast.net with comcast id DAwD1h00S03Bn0N8gAwKJT; Wed, 27 Jul 2011 22:56:47 +0000 Message-ID: <4E30976D.2070700@alum.mit.edu> Date: Wed, 27 Jul 2011 18:55:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Comment on framework - who gives the hint X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 22:56:29 -0000 On 7/27/11 6:13 PM, Elwell, John wrote: > The framework is based on the following general principle: > - receiver optionally sends hints as to what it would like to receive; > - sender indicates what it can send; > - receives selects what it will receive. > > Another possibility would be: > - transmitter optionally sends hints as to what it can send; > - receiver indicates what it can receive; > - transmitter selects what it will send. > > I don't have any opinion as to which is the better - in fact I tend to lean towards the first, but I can't give a reason. But it would be good to know if there are specific reasons for going with the first rather than the second. I also don't know which is better. Its not apparent to me that there is a difference. Either way, it will take a 3-way handshake to negotiate. And since each side is both a sender and a receiver, it will take a 3-way handshake for each. At best that will take four messages. (This could be done with o/a and preconditions. But that's mechanism and we aren't ready to start discussing that yet.) Thanks, Paul > John > > > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Even.roni@huawei.com Wed Jul 27 20:32:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93BD21F8891 for ; Wed, 27 Jul 2011 20:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 gXBV9Yioh8FD for ; Wed, 27 Jul 2011 20:32:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB8621F8880 for ; Wed, 27 Jul 2011 20:32:08 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP000MILXSJVV@szxga05-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 11:31:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP0002Z6XSILV@szxga05-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 11:31:31 +0800 (CST) Received: from windows8d787f9 (dhcp-438f.meeting.ietf.org [130.129.67.143]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP000ANDXSFQX@szxml11-in.huawei.com>; Thu, 28 Jul 2011 11:31:30 +0800 (CST) Date: Thu, 28 Jul 2011 06:28:47 +0300 From: Roni Even In-reply-to: <4E309135.7070408@alum.mit.edu> To: 'Paul Kyzivat' , clue@ietf.org Message-id: <001b01cc4cd6$77d28760$67779620$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcxMrMIDk+gl6gl8TbaLA3QGADrbCQAKUwFA References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> <4E309135.7070408@alum.mit.edu> Subject: Re: [clue] Comment on the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 03:32:09 -0000 Hi, HTTP is not defining a common data sharing protocol. WebEx may be carried over HTTP but the data sharing application is not standard. What I meant is that it can either be something that is a common data sharing protocol or something that is carried as an RTP payload which require some common defined protocol on top. > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, July 28, 2011 1:29 AM > To: clue@ietf.org > Subject: Re: [clue] Comment on the presentation use case > > On 7/27/11 6:07 PM, Roni Even wrote: > > Hi Stephane, > > > > Is there a standard protocol that is used for conveying this > > information, is it RTP based. > > AFAIK this is often http. (E.g. webex) > > > To me this is a separate application that can be integrated in the > > application level and not as part of the multistream. > > I guess this depends on whether the support for it is integrated into > the "room", or is just incidental equipment brought by the users, not > formally related to the telepresence session. > > Thanks, > Paul > (speaking as an individual) > > > Roni > > > > *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of > > *stephane.cazeaux@orange-ftgroup.com > > *Sent:* Thursday, July 21, 2011 2:33 PM > > *To:* clue@ietf.org > > *Subject:* [clue] Comment on the presentation use case* > > > > ** > > > > *Hi,* > > > > ** > > > > *The presentation use case as described in the use-cases document is > > based on the assumption that the presentation stream relies on a > video > > stream, and is limited to usage of presentation video streams. But we > > could also consider collaborative use cases, meaningful for > > telepresence, which are not covered by the existing text.* > > > > *I propose to complete the existing text as follows:* > > > > ** > > > > *Furthermore, although most today's systems use video streams for > > presentations, there are use cases where this is not suitable. For > example:* > > > > *- The professor which shares an electronic whiteboard (could be a > > whiteboard application on a PC, with screen capture of the PC) where > all > > students can participate. Students will take control of the shared > > whiteboard in turns.* > > > > *- In a multipoint meeting, a shared document can be kept always > visible > > in a screen, while other documents are presented on other screens > (with > > possible in turns presentation). For instance, for the purpose of > shared > > design document, notes taking, polls, etc. A shared document implies > > that all participants can modify it in turns.* > > > > *"* > > > > ** > > > > ** > > > > *St ephane. v> > > * > > > > * > > * > > > > *_______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > * > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Jul 27 20:36:19 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC31411E80B0 for ; Wed, 27 Jul 2011 20:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 Q8tiJujIPyal for ; Wed, 27 Jul 2011 20:36:18 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F078921F8B01 for ; Wed, 27 Jul 2011 20:36:16 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Wed, 27 Jul 2011 20:36:16 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 27 Jul 2011 20:36:14 -0700 Thread-Topic: [clue] Comment on rendering slides Thread-Index: AcxMYMEI7arXFL4kSTuLE8bWLtVVQgAdhpNQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802B0B@CRPMBOXPRD01.polycom.com> References: <4E2EDEB7.1080708@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A61AE802559@CRPMBOXPRD01.polycom.com> <4E3011CE.3070808@alum.mit.edu> In-Reply-To: <4E3011CE.3070808@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Comment on rendering slides X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 03:36:20 -0000 Paul, Maybe separate *dialog* is the wrong word. What I mean is a device that is= both a Media Consumer and Provider will send/receive messages communicatin= g information about what it will send and what it will receive, and those t= wo sets of information are independent of each other. But I guess you can = call it a single dialog. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Wednesday, July 27, 2011 9:26 AM > To: clue@ietf.org > Subject: Re: [clue] Comment on rendering slides >=20 > On 7/26/11 5:43 PM, Duckworth, Mark wrote: > > I think we are really talking about draft-romanow-clue-framework-00 > and not the rendering slides, but I left the subject line the same :) > > > > Yes, the framework allows both sides of an exchange to act as both a > Media Provider (sender) and a Media Consumer (receiver), with a > separate dialog for each direction, so the resulting media flows can be > asymmetric. >=20 > We aren't really discussing mechanism in detail yet, so this is > probably > premature. But do you *really* mean a separate *dialog* in each > direction??? That seems very weird. I can understand how there might be > a separate m-line for each direction, which allows the properties to > differ radically. >=20 > > As for the receiver indicating preferences up front, yes, it is > partly there in the document, that is what the "hints" mentioned in > section 7 are for. The concept is there, but exactly what to do with > it is not yet fleshed out. >=20 > OK. That wasn't entirely obvious, though that is what I had inferred. >=20 > > And for the receiver indicating what it wants the streams to contain, > that is partly there too if the sender advertises choices that have > different attributes. So for example a receiver could choose between a > "composed" video stream and a "switched" video stream. Exactly how the > composition and switching is done is not specified in the framework. > If there is a need to exchange this information, perhaps it could be > added, but I don't think the use case document has any cases yet where > this would be required, and I didn't see it in the requirements > document either. > > > > The use case document also mentions ability to choose media from a > specific source, for example I might want to always see a particular > person in the conference even though that person rarely speaks. This > type of source selection is not yet covered in the framework. For > other types of source selection, I think we need more use cases to > inform requirements. > > > > I'm not sure either if this framework can or should be mapped on to > SDP offer/answer. That needs further discussion. >=20 > I am in agreement with John here. >=20 > With o/a, one side or the other is "first". For both sides to indicate > a > preference, then receive an advertisement, then make a selection, two > or > even three o/a cycles may be needed. But that is doable. >=20 > Thanks, > Paul >=20 > > Mark Duckworth > > > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of > >> Paul Kyzivat > >> Sent: Tuesday, July 26, 2011 11:35 AM > >> To: clue@ietf.org > >> Subject: Re: [clue] Comment on rendering slides > >> > >> (as individual) > >> > >> I largely agree with Charles. > >> > >> ISTM that what this is developing into is a more extensive > negotiation > >> than is possible with one round of o/a exchange. > >> > >> Conceivably this could be done using multiple o/a exchanges, but > that > >> may not be the best way. > >> > >> It seems to me that when a box advertises what it can provide, it > >> probably doesn't want to be required to have all of those already > >> available. IOW, the advertisement is like a menu from which the > >> recipient can order, rather than a buffet from which the recipient > can > >> take things. (An SDP offer is a buffet.) The sender can then defer > >> cooking the item until it knows it has an order. > >> > >> The other issue is whether the sender can realistically enumerate > the > >> entire menu. Perhaps there are too many variations possible. In that > >> case the "customer" may want to request something that is not on the > >> menu. Maybe that then gets added to the menu, and maybe not. > >> > >> Whether we need to go that way may depend on the mechanism used to > >> deliver the advertisement/menu. If its done via SDP then the size of > >> the > >> menu is probably quite limited. If it is done some other way, then > >> maybe > >> not. > >> > >> Thanks, > >> Paul > >> > >> On 7/26/11 10:51 AM, Charles Eckel (eckelcu) wrote: > >>> I would prefer to continue to use the existing SDP mechanism to > >> describe > >>> what an endpoint is capable of receiving. I think the existing > >> framework > >>> draft provides a mechanism for a sender to indicate what it can > send, > >>> and for a receiver to select which of those it wants to receive. > >>> As for asymmetry, I read the framework as allowing each side to act > >> as a > >>> sender and a receiver, facilitating asymmetry. If others think this > >> is > >>> not the case, then I agree with John that we need to clarify that. > >>> > >>> What I think is missing is: > >>> - a mechanism for a receiver to indicate a preference for, or a > >> request > >>> for, a specific rendering, or layout, or format (i.e. not just that > I > >>> want one H.264 video stream and one G.722 audio stream, but what I > >> want > >>> each of those to contain). > >>> > >>> The main benefit of doing this is that it might allow a sender to > >> tailor > >>> its description of what it can send to include options that the > >> receiver > >>> requested, as opposed to the sender trying to list every single > >> possible > >>> combination it can imagine. > >>> There are many ways to do this, and I do not want to get into the > >>> details here, but if we agree that we need a mechanism for a > receiver > >> to > >>> advertise its preference or request something specific from the > >> sender > >>> along these line, then I think we can cover Christer's rendering > use > >>> cases as well as some of the use cases I mentioned previously > >> regarding > >>> composition. If we list out the use cases, we can make sure this > >>> mechanism is sufficient to address all of them. > >>> > >>> Cheers, > >>> Charles > >>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > Behalf > >>> Of Elwell, John > >>>> Sent: Tuesday, July 26, 2011 8:33 AM > >>>> To: clue@ietf.org > >>>> Subject: [clue] Comment on rendering slides > >>>> > >>>> Based on this morning's discussion, I have a problem with the > >> proposal > >>> on the last slide: > >>>> > >>>> "REQ-x: It MUST be possible for a client to indicate, per > media > >>> stream, supported rendering > >>>> type(s). > >>>> REQ-y: It MUST be possible to inform a client, per media > >>> stream, the rendering type(s) applied to > >>>> the stream. " > >>>> > >>>> I believe this is a more asymmetric problem, and perhaps needs to > be > >>> expressed in terms of: > >>>> "REQ-x: It MUST be possible for a client to indicate, per > media > >>> stream, rendering type(s) it is > >>>> able to transmit. > >>>> > >>>> REQ-y: It MUST be possible to inform a client, per media > >>> stream, the rendering type(s) that can > >>>> be received." > >>>> > >>>> (where the media types to be received would be selected from those > >>> able to be transmitted by the peer) > >>>> > >>>> Notwithstanding, of course, that we need to explore more use cases > >> to > >>> see whether this really fits. > >>>> > >>>> John > >>>> > >>>> John Elwell > >>>> Tel: +44 1908 817801 (office and mobile) > >>>> Email: john.elwell@siemens-enterprise.com > >>>> http://www.siemens-enterprise.com/uk/ > >>>> > >>>> Siemens Enterprise Communications Limited. > >>>> Registered office: Brickhill Street, Willen Lake, Milton Keynes, > >> MK15 > >>> 0DJ. > >>>> Registered No: 5903714, England. > >>>> > >>>> Siemens Enterprise Communications Limited is a Trademark Licensee > of > >>> Siemens AG. > >>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Jul 27 20:43:52 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2AB21F8B3D for ; Wed, 27 Jul 2011 20:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 mONiDkQlwF1l for ; Wed, 27 Jul 2011 20:43:52 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 111B321F8B3C for ; Wed, 27 Jul 2011 20:43:50 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by Crpehubprd01.polycom.com ([fe80::27:216a:613a:350c%13]) with mapi; Wed, 27 Jul 2011 20:43:50 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 27 Jul 2011 20:43:48 -0700 Thread-Topic: Comment on framework - who gives the hint Thread-Index: AcxMqmQSQWS7gQMfRVmOILKsMyyz8QALc/nw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802B0C@CRPMBOXPRD01.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Comment on framework - who gives the hint X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 03:43:53 -0000 I also prefer the first way. It seems to me the receiver's final preferenc= e in making the choice is more important than the sender's preference. It = is the receiver that has to do something useful with the streams it receive= s, so it should be the one to make the final choice. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Wednesday, July 27, 2011 6:13 PM > To: clue@ietf.org > Subject: [clue] Comment on framework - who gives the hint >=20 > The framework is based on the following general principle: > - receiver optionally sends hints as to what it would like to receive; > - sender indicates what it can send; > - receives selects what it will receive. >=20 > Another possibility would be: > - transmitter optionally sends hints as to what it can send; > - receiver indicates what it can receive; > - transmitter selects what it will send. >=20 > I don't have any opinion as to which is the better - in fact I tend to > lean towards the first, but I can't give a reason. But it would be good > to know if there are specific reasons for going with the first rather > than the second. >=20 > John >=20 >=20 > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ >=20 > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. > Registered No: 5903714, England. >=20 > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Wed Jul 27 20:49:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F91921F8B8E for ; Wed, 27 Jul 2011 20:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6QTJGp0ZpAM for ; Wed, 27 Jul 2011 20:49:08 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0121F8BA1 for ; Wed, 27 Jul 2011 20:49:06 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Wed, 27 Jul 2011 20:49:05 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 27 Jul 2011 20:49:03 -0700 Thread-Topic: [clue] framework - capture set Thread-Index: AcxMqGvImh9NvgMbTN6/eAlpxjefCAAMEFgA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802B0D@CRPMBOXPRD01.polycom.com> References: <00e201cc4ca8$6e539590$4afac0b0$%roni@huawei.com> In-Reply-To: <00e201cc4ca8$6e539590$4afac0b0$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61AE802B0DCRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] framework - capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 03:49:09 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802B0DCRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, the attributes "composed" and "scale" can be used to differentiate bet= ween a zoomed out view and a composite view. I expect the multi view case can be addressed by adding a video capture att= ribute to give more information about the relative viewpoints of the camera= s for each video capture. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, July 27, 2011 5:59 PM To: clue@ietf.org Subject: [clue] framework - capture set Hi, The capture set example has (VC4 - zoomed out view of all people in the roo= m.). Now is there a way to differentiate between zoom out view and composit= e view of all cameras to the 3 to 1 screen use case? How do you see the extension to support multi view is there is no way to de= scribe the camera view port explicitly? Roni --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802B0DCRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, the attributes “composed” and “scale&#= 8221; can be used to differentiate between a zoomed out view and a composit= e view.

 

I expect the multi view case can be addressed by adding a video ca= pture attribute to give more information about the relative viewpoints of t= he cameras for each video capture.

 

Mark

 

From: clue-bounces@ietf.org [mailto:clue-bou= nces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, Jul= y 27, 2011 5:59 PM
To: clue@ietf.org
Subject: [clue] fr= amework - capture set

 

Hi,

The capture set example has (VC4 - zoomed out view of all people in the = room.). Now is there a way to differentiate between zoom out view and compo= site view of all cameras to the 3 to 1 screen use case?

 

How do you = see the extension to support multi view is there is no way to describe the = camera view port explicitly?

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>&nb= sp;

Roni

 <= /o:p>

= --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802B0DCRPMBOXPRD01pol_-- From pkyzivat@alum.mit.edu Wed Jul 27 21:05:01 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCF821F872F for ; Wed, 27 Jul 2011 21:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGd6sxBvZa-q for ; Wed, 27 Jul 2011 21:05:01 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id CC8FE21F871E for ; Wed, 27 Jul 2011 21:05:00 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id DG0w1h0031c6gX85DG51wp; Thu, 28 Jul 2011 04:05:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([70.25.120.2]) by omta23.westchester.pa.mail.comcast.net with comcast id DG4n1h00Z03Bn0N3jG4rxK; Thu, 28 Jul 2011 04:04:59 +0000 Message-ID: <4E30DFDE.3040601@alum.mit.edu> Date: Thu, 28 Jul 2011 00:04:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Roni Even References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com> <4E309135.7070408@alum.mit.edu> <001b01cc4cd6$77d28760$67779620$%roni@huawei.com> In-Reply-To: <001b01cc4cd6$77d28760$67779620$%roni@huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Comment on the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 04:05:01 -0000 On 7/27/11 11:28 PM, Roni Even wrote: > Hi, > HTTP is not defining a common data sharing protocol. WebEx may be carried > over HTTP but the data sharing application is not standard. What I meant is > that it can either be something that is a common data sharing protocol or > something that is carried as an RTP payload which require some common > defined protocol on top. I was being a bit tongue in cheek, though not entirely. Of course you are right - that if you want to push data to everybody you need more. But data sharing by pointing a video camera at a piece of paper is a tad out of date. Connecting the video port on a user's computer as a video source and distributing it with the other video is better than that. But its not nearly as convenient as webex or any of its competitors. It isn't entirely clear that its *necessary* to bundle the data sharing application with the telepresence protocols. Its kind of limiting since the web apps evolve very rapidly. Perhaps we should be doing the opposite of that: providing a way to embed the control of the telepresence system into a web app. Thanks, Paul >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Thursday, July 28, 2011 1:29 AM >> To: clue@ietf.org >> Subject: Re: [clue] Comment on the presentation use case >> >> On 7/27/11 6:07 PM, Roni Even wrote: >>> Hi Stephane, >>> >>> Is there a standard protocol that is used for conveying this >>> information, is it RTP based. >> >> AFAIK this is often http. (E.g. webex) >> >>> To me this is a separate application that can be integrated in the >>> application level and not as part of the multistream. >> >> I guess this depends on whether the support for it is integrated into >> the "room", or is just incidental equipment brought by the users, not >> formally related to the telepresence session. >> >> Thanks, >> Paul >> (speaking as an individual) >> >>> Roni >>> >>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>> *stephane.cazeaux@orange-ftgroup.com >>> *Sent:* Thursday, July 21, 2011 2:33 PM >>> *To:* clue@ietf.org >>> *Subject:* [clue] Comment on the presentation use case* >>> >>> ** >>> >>> *Hi,* >>> >>> ** >>> >>> *The presentation use case as described in the use-cases document is >>> based on the assumption that the presentation stream relies on a >> video >>> stream, and is limited to usage of presentation video streams. But we >>> could also consider collaborative use cases, meaningful for >>> telepresence, which are not covered by the existing text.* >>> >>> *I propose to complete the existing text as follows:* >>> >>> ** >>> >>> *Furthermore, although most today's systems use video streams for >>> presentations, there are use cases where this is not suitable. For >> example:* >>> >>> *- The professor which shares an electronic whiteboard (could be a >>> whiteboard application on a PC, with screen capture of the PC) where >> all >>> students can participate. Students will take control of the shared >>> whiteboard in turns.* >>> >>> *- In a multipoint meeting, a shared document can be kept always >> visible >>> in a screen, while other documents are presented on other screens >> (with >>> possible in turns presentation). For instance, for the purpose of >> shared >>> design document, notes taking, polls, etc. A shared document implies >>> that all participants can modify it in turns.* >>> >>> *"* >>> >>> ** >>> >>> ** >>> >>> *St ephane. v> >>> * >>> >>> * >>> * >>> >>> *_______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> * >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From Even.roni@huawei.com Wed Jul 27 21:20:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE96911E8089 for ; Wed, 27 Jul 2011 21:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.555 X-Spam-Level: X-Spam-Status: No, score=-106.555 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dmUOG1LPTQka for ; Wed, 27 Jul 2011 21:20:08 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B475411E80A3 for ; Wed, 27 Jul 2011 21:20:07 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100DU500FYA@szxga04-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 12:19:27 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100JAQ00FIH@szxga04-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 12:19:27 +0800 (CST) Received: from windows8d787f9 (dhcp-438f.meeting.ietf.org [130.129.67.143]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP100A7V00BQX@szxml11-in.huawei.com>; Thu, 28 Jul 2011 12:19:26 +0800 (CST) Date: Thu, 28 Jul 2011 07:16:42 +0300 From: Roni Even In-reply-to: <44C6B6B2D0CF424AA90B6055548D7A61AE802B0D@CRPMBOXPRD01.polycom.com> To: "'Duckworth, Mark'" , clue@ietf.org Message-id: <002901cc4cdd$29beb830$7d3c2890$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_GP8CGVCqAcklRLhXIPTs8Q)" Content-language: en-us Thread-index: AcxMqGvImh9NvgMbTN6/eAlpxjefCAAMEFgAAACGetA= References: <00e201cc4ca8$6e539590$4afac0b0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61AE802B0D@CRPMBOXPRD01.polycom.com> Subject: Re: [clue] framework - capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 04:20:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_GP8CGVCqAcklRLhXIPTs8Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Mark, Composed (true/false) does not provide any meaningful information, composed from what? See my question on the examples in the draft. How do you know from the attributes that the meaning is what in the comment you have at the beginning in the following examples. 4. VC3- (the loudest panel stream), encoding group:EG1, attributes: purpose=main;auto-switched:yes 5. VC4- (the loudest panel stream with PiPs), encoding group:EG1, attributes: purpose=main; composed=true; auto-switched:yes 6. VC5- (the zoomed out view of all people in the room), encoding group:EG1, attributes: purpose=main;auto-switched:no VC3 is switched but maybe it is also used some zoom. So what is being switched? VC4 - composed from what where do I see that it is the loudest panel with two PiPs and not just the loudest speaker with one PiP? VC5- how do I know from the attributes that is a zoomed view of all the people in the room As for scale An optional integer valued variable indicating the spatial scale of the video capture, for example centimeters for horizontal image width. I am not sure what it means, and saying for example is not a definition. Spatial scale between what? Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, July 28, 2011 6:49 AM To: clue@ietf.org Subject: Re: [clue] framework - capture set Yes, the attributes "composed" and "scale" can be used to differentiate between a zoomed out view and a composite view. I expect the multi view case can be addressed by adding a video capture attribute to give more information about the relative viewpoints of the cameras for each video capture. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, July 27, 2011 5:59 PM To: clue@ietf.org Subject: [clue] framework - capture set Hi, The capture set example has (VC4 - zoomed out view of all people in the room.). Now is there a way to differentiate between zoom out view and composite view of all cameras to the 3 to 1 screen use case? How do you see the extension to support multi view is there is no way to describe the camera view port explicitly? Roni _____ --Boundary_(ID_GP8CGVCqAcklRLhXIPTs8Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Mark,

Composed (true/false) = does not provide any meaningful information, composed from what? See my = question on the examples in the draft.

 

How do you know from the = attributes that the meaning is what in the comment you have at the = beginning in the following examples.

 

   4.  VC3- (the loudest panel stream), encoding = group:EG1, attributes:

       = purpose=3Dmain;auto-switched:yes

 

   5.  VC4- (the = loudest panel stream with PiPs), encoding = group:EG1,

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

 

   6.  VC5- (the zoomed out view of all people in = the room), encoding

       = group:EG1, attributes: = purpose=3Dmain;auto-switched:no

 

 

VC3 is switched but = maybe it is also used some zoom.  So what is being = switched?

VC4 – composed from what where do I see = that it is the loudest panel with two PiPs and not just the loudest = speaker with one PiP?

VC5- how do I know from the attributes that is a = zoomed view of all the people in the room

 

As for = scale

   An optional integer = valued variable indicating the spatial scale of

  =  the video capture, for example centimeters for horizontal = image

   = width.

 

I am not sure what it = means, and saying for example is not a definition. Spatial scale between = what?

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Duckworth, Mark
Sent: Thursday, July 28, 2011 6:49 = AM
To: clue@ietf.org
Subject: Re: [clue] framework - = capture set

 

Yes, the attributes “composed” and = “scale” can be used to differentiate between a zoomed out = view and a composite view.

 

I expect the multi view = case can be addressed by adding a video capture attribute to give more = information about the relative viewpoints of the cameras for each video = capture.

 

Mark

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Roni Even
Sent: Wednesday, July 27, 2011 5:59 = PM
To: clue@ietf.org
Subject: [clue] framework - = capture set

 

Hi,

The = capture set example has (VC4 - zoomed out view of all people in the = room.). Now is there a way to differentiate between zoom out view and = composite view of all cameras to the 3 to 1 screen use = case?

 =

How do you = see the extension to support multi view is there is no way to describe = the camera view port explicitly?

 =

Roni

 

= --Boundary_(ID_GP8CGVCqAcklRLhXIPTs8Q)-- From bruno.chatras@orange-ftgroup.com Wed Jul 27 23:37:38 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F404421F8C24 for ; Wed, 27 Jul 2011 23:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 eUVucq3wn6HM for ; Wed, 27 Jul 2011 23:37:37 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id AD19821F8C23 for ; Wed, 27 Jul 2011 23:37:36 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D4A9E8B8008; Thu, 28 Jul 2011 08:38:24 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id CAD688B8004; Thu, 28 Jul 2011 08:38:24 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 08:37:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2011 08:37:34 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4E30DFDE.3040601@alum.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comment on the presentation use case Thread-Index: AcxM24msK+0jeMyxRqCJ5NJxFpO8OQAFUV9Q References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> From: To: , X-OriginalArrivalTime: 28 Jul 2011 06:37:35.0729 (UTC) FILETIME=[D6401E10:01CC4CF0] Cc: clue@ietf.org Subject: Re: [clue] Comment on the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 06:37:38 -0000 I think we should take a look to=20 http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 Bruno > -----Message d'origine----- > De=A0: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part = de > Paul Kyzivat > Envoy=E9=A0: jeudi 28 juillet 2011 06:05 > =C0=A0: Roni Even > Cc=A0: clue@ietf.org > Objet=A0: Re: [clue] Comment on the presentation use case >=20 > On 7/27/11 11:28 PM, Roni Even wrote: > > Hi, > > HTTP is not defining a common data sharing protocol. WebEx may be > carried > > over HTTP but the data sharing application is not standard. What I > meant is > > that it can either be something that is a common data sharing > protocol or > > something that is carried as an RTP payload which require some = common > > defined protocol on top. >=20 > I was being a bit tongue in cheek, though not entirely. > Of course you are right - that if you want to push data to everybody > you > need more. >=20 > But data sharing by pointing a video camera at a piece of paper is a > tad > out of date. Connecting the video port on a user's computer as a video > source and distributing it with the other video is better than that. > But > its not nearly as convenient as webex or any of its competitors. >=20 > It isn't entirely clear that its *necessary* to bundle the data = sharing > application with the telepresence protocols. Its kind of limiting = since > the web apps evolve very rapidly. Perhaps we should be doing the > opposite of that: providing a way to embed the control of the > telepresence system into a web app. >=20 > Thanks, > Paul >=20 > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On = Behalf > Of > >> Paul Kyzivat > >> Sent: Thursday, July 28, 2011 1:29 AM > >> To: clue@ietf.org > >> Subject: Re: [clue] Comment on the presentation use case > >> > >> On 7/27/11 6:07 PM, Roni Even wrote: > >>> Hi Stephane, > >>> > >>> Is there a standard protocol that is used for conveying this > >>> information, is it RTP based. > >> > >> AFAIK this is often http. (E.g. webex) > >> > >>> To me this is a separate application that can be integrated in the > >>> application level and not as part of the multistream. > >> > >> I guess this depends on whether the support for it is integrated > into > >> the "room", or is just incidental equipment brought by the users, > not > >> formally related to the telepresence session. > >> > >> Thanks, > >> Paul > >> (speaking as an individual) > >> > >>> Roni > >>> > >>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf = Of > >>> *stephane.cazeaux@orange-ftgroup.com > >>> *Sent:* Thursday, July 21, 2011 2:33 PM > >>> *To:* clue@ietf.org > >>> *Subject:* [clue] Comment on the presentation use case* > >>> > >>> ** > >>> > >>> *Hi,* > >>> > >>> ** > >>> > >>> *The presentation use case as described in the use-cases document > is > >>> based on the assumption that the presentation stream relies on a > >> video > >>> stream, and is limited to usage of presentation video streams. But > we > >>> could also consider collaborative use cases, meaningful for > >>> telepresence, which are not covered by the existing text.* > >>> > >>> *I propose to complete the existing text as follows:* > >>> > >>> ** > >>> > >>> *Furthermore, although most today's systems use video streams for > >>> presentations, there are use cases where this is not suitable. For > >> example:* > >>> > >>> *- The professor which shares an electronic whiteboard (could be a > >>> whiteboard application on a PC, with screen capture of the PC) > where > >> all > >>> students can participate. Students will take control of the shared > >>> whiteboard in turns.* > >>> > >>> *- In a multipoint meeting, a shared document can be kept always > >> visible > >>> in a screen, while other documents are presented on other screens > >> (with > >>> possible in turns presentation). For instance, for the purpose of > >> shared > >>> design document, notes taking, polls, etc. A shared document > implies > >>> that all participants can modify it in turns.* > >>> > >>> *"* > >>> > >>> ** > >>> > >>> ** > >>> > >>> *St ephane. v> > >>> * > >>> > >>> * > >>> * > >>> > >>> *_______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >>> * > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > > > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Thu Jul 28 04:41:44 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0426A21F8987 for ; Thu, 28 Jul 2011 04:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 XDfJbLf1PV3X for ; Thu, 28 Jul 2011 04:41:43 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 633A721F8853 for ; Thu, 28 Jul 2011 04:41:42 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta04.emeryville.ca.mail.comcast.net with comcast id DPbn1h0041u4NiLA4Phepm; Thu, 28 Jul 2011 11:41:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([70.25.120.2]) by omta21.emeryville.ca.mail.comcast.net with comcast id DPfR1h02803Bn0N8hPfaSD; Thu, 28 Jul 2011 11:39:53 +0000 Message-ID: <4E314AD3.1030406@alum.mit.edu> Date: Thu, 28 Jul 2011 07:41:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: bruno.chatras@orange-ftgroup.com References: <00ec01cc4ca9$9cc14e80$d643eb80$%roni@huawei.com><4E309135.7070408@alum.mit.edu><001b01cc4cd6$77d28760$67779620$%roni@huawei.com> <4E30DFDE.3040601@alum.mit.edu> <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141031F2E5E@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Comment on the presentation use case X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 11:41:44 -0000 On 7/28/11 2:37 AM, bruno.chatras@orange-ftgroup.com wrote: > I think we should take a look to > http://tools.ietf.org/html/draft-garcia-mmusic-sdp-collaboration-00 Maybe. But that is almost orthogonal to what I was suggesting. THanks, Paul (as individual) > Bruno > >> -----Message d'origine----- >> De : clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] De la part de >> Paul Kyzivat >> Envoyé : jeudi 28 juillet 2011 06:05 >> À : Roni Even >> Cc : clue@ietf.org >> Objet : Re: [clue] Comment on the presentation use case >> >> On 7/27/11 11:28 PM, Roni Even wrote: >>> Hi, >>> HTTP is not defining a common data sharing protocol. WebEx may be >> carried >>> over HTTP but the data sharing application is not standard. What I >> meant is >>> that it can either be something that is a common data sharing >> protocol or >>> something that is carried as an RTP payload which require some common >>> defined protocol on top. >> >> I was being a bit tongue in cheek, though not entirely. >> Of course you are right - that if you want to push data to everybody >> you >> need more. >> >> But data sharing by pointing a video camera at a piece of paper is a >> tad >> out of date. Connecting the video port on a user's computer as a video >> source and distributing it with the other video is better than that. >> But >> its not nearly as convenient as webex or any of its competitors. >> >> It isn't entirely clear that its *necessary* to bundle the data sharing >> application with the telepresence protocols. Its kind of limiting since >> the web apps evolve very rapidly. Perhaps we should be doing the >> opposite of that: providing a way to embed the control of the >> telepresence system into a web app. >> >> Thanks, >> Paul >> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of >>>> Paul Kyzivat >>>> Sent: Thursday, July 28, 2011 1:29 AM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Comment on the presentation use case >>>> >>>> On 7/27/11 6:07 PM, Roni Even wrote: >>>>> Hi Stephane, >>>>> >>>>> Is there a standard protocol that is used for conveying this >>>>> information, is it RTP based. >>>> >>>> AFAIK this is often http. (E.g. webex) >>>> >>>>> To me this is a separate application that can be integrated in the >>>>> application level and not as part of the multistream. >>>> >>>> I guess this depends on whether the support for it is integrated >> into >>>> the "room", or is just incidental equipment brought by the users, >> not >>>> formally related to the telepresence session. >>>> >>>> Thanks, >>>> Paul >>>> (speaking as an individual) >>>> >>>>> Roni >>>>> >>>>> *clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of >>>>> *stephane.cazeaux@orange-ftgroup.com >>>>> *Sent:* Thursday, July 21, 2011 2:33 PM >>>>> *To:* clue@ietf.org >>>>> *Subject:* [clue] Comment on the presentation use case* >>>>> >>>>> ** >>>>> >>>>> *Hi,* >>>>> >>>>> ** >>>>> >>>>> *The presentation use case as described in the use-cases document >> is >>>>> based on the assumption that the presentation stream relies on a >>>> video >>>>> stream, and is limited to usage of presentation video streams. But >> we >>>>> could also consider collaborative use cases, meaningful for >>>>> telepresence, which are not covered by the existing text.* >>>>> >>>>> *I propose to complete the existing text as follows:* >>>>> >>>>> ** >>>>> >>>>> *Furthermore, although most today's systems use video streams for >>>>> presentations, there are use cases where this is not suitable. For >>>> example:* >>>>> >>>>> *- The professor which shares an electronic whiteboard (could be a >>>>> whiteboard application on a PC, with screen capture of the PC) >> where >>>> all >>>>> students can participate. Students will take control of the shared >>>>> whiteboard in turns.* >>>>> >>>>> *- In a multipoint meeting, a shared document can be kept always >>>> visible >>>>> in a screen, while other documents are presented on other screens >>>> (with >>>>> possible in turns presentation). For instance, for the purpose of >>>> shared >>>>> design document, notes taking, polls, etc. A shared document >> implies >>>>> that all participants can modify it in turns.* >>>>> >>>>> *"* >>>>> >>>>> ** >>>>> >>>>> ** >>>>> >>>>> *St ephane. v> >>>>> * >>>>> >>>>> * >>>>> * >>>>> >>>>> *_______________________________________________ >>>>> 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 ietf@meetecho.com Thu Jul 28 05:31:27 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8A21F8B31 for ; Thu, 28 Jul 2011 05:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=0.027, 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 sly6hNe0aWfY for ; Thu, 28 Jul 2011 05:31:26 -0700 (PDT) Received: from smtplqs02.aruba.it (smtplqs-out48.aruba.it [62.149.158.88]) by ietfa.amsl.com (Postfix) with SMTP id 4F8CB21F8760 for ; Thu, 28 Jul 2011 05:31:25 -0700 (PDT) Received: (qmail 19590 invoked by uid 89); 28 Jul 2011 12:31:23 -0000 Received: from unknown (HELO smtpw2.aruba.it) (62.149.128.188) by smtplqs02.aruba.it with SMTP; 28 Jul 2011 12:31:23 -0000 Received: (qmail 23618 invoked by uid 89); 28 Jul 2011 12:31:23 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw2.ad.aruba.it with SMTP; 28 Jul 2011 12:31:23 -0000 Date: Thu, 28 Jul 2011 14:31:23 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: clue@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 130.129.21.177 X-Spam-Rating: smtpw2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs02.aruba.it 1.6.2 0/1000/N Subject: [clue] Meetecho support for CLUE WG meeting session X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 12:31:27 -0000 Hi all,=0A=0Aa virtual room has been reserved on the Meetecho system. =0A= =0AAccess to the on-line session (including audio and video streams) will= be available from 8:50am.=0ATo get into the room, just click on the prop= er link on the remote participation page:=0Ahttp://www.ietf.org/meeting/8= 1/remote-participation.html#Meetecho=0A=0AThe Meetecho session automatica= lly logs you into the standard IETF jabber room. So, from there, you can = have an integrated experience involving all media and allowing you to int= eract with the room.=0A=0AA tutorial of interactivity features of the too= l can be found at:=0Ahttp://www.meetecho.com/ietf81/tutorials=0A=0AFor fu= rther information you can contact us at ietf-support@meetecho.com.=0A=0AC= heers,=0Athe Meetecho Team From john.elwell@siemens-enterprise.com Thu Jul 28 06:15:10 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E5821F8BBC for ; Thu, 28 Jul 2011 06:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=-0.965, 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 HCzUylY3Buf7 for ; Thu, 28 Jul 2011 06:15:09 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 524C621F8AB8 for ; Thu, 28 Jul 2011 06:15:09 -0700 (PDT) Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 8995023F05D1 for ; Thu, 28 Jul 2011 15:15:08 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 28 Jul 2011 15:15:08 +0200 From: "Elwell, John" To: "clue@ietf.org" Date: Thu, 28 Jul 2011 15:15:06 +0200 Thread-Topic: Left and right Thread-Index: AcxNKF4jVyFZG9R7TkuYRZlPjUybyA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] Left and right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 13:15:10 -0000 I couldn't formulate this comment in time to come to the mic, but has any t= hought been given to defining left and right in a particular way, to be use= d unless stated otherwise. For example, Left: Unless stated otherwise, on the left from the point of view of an obs= erver of rendered media. John John Elwell Tel: +44 1908 817801 (office and mobile) Email: john.elwell@siemens-enterprise.com http://www.siemens-enterprise.com/uk/ Siemens Enterprise Communications Limited. Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ. Registered No: 5903714, England. Siemens Enterprise Communications Limited is a Trademark Licensee of Siemen= s AG. = From Even.roni@huawei.com Thu Jul 28 06:25:29 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66FD21F874E for ; Thu, 28 Jul 2011 06:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 o4J9UF2P51jJ for ; Thu, 28 Jul 2011 06:25:29 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id ACEA321F86BF for ; Thu, 28 Jul 2011 06:25:28 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP100C8DP6M7R@szxga05-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 21:23:10 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP10036RP6MXZ@szxga05-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 21:23:10 +0800 (CST) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP100CWAP6I46@szxml12-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 21:23:10 +0800 (CST) Date: Thu, 28 Jul 2011 16:20:26 +0300 From: Roni Even To: clue@ietf.org Message-id: <00b701cc4d29$1f3ab200$5db01600$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dk9QpDwcj97TGrBE3wWRfg)" Content-language: en-us Thread-index: AcxNKRyCkdcQHjVRSAyaQlaurfLfHw== Subject: [clue] MCU from H.323 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 13:25:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_dk9QpDwcj97TGrBE3wWRfg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi multipoint control unit: The Multipoint Control Unit (MCU) is an endpoint on the network which provides the capability for three or more terminals and Gateways to participate in a multipoint conference. It may also connect two terminals in a point-to-point conference which may later develop into a multipoint conference. The MCU generally operates in the fashion of an H.231 MCU; however, an audio processor is not mandatory. The MCU consists of two parts: a mandatory Multipoint Controller and optional Multipoint Processors. In the simplest case, an MCU may consist only of an MC with no MPs. An MCU may also be brought into a conference by the Gatekeeper without being explicitly called by one of the endpoints. 3.35 multipoint controller: The Multipoint Controller (MC) is an H.323 entity on the network which provides for the control of three or more terminals participating in a multipoint conference. It may also connect two terminals in a point-to-point conference which may later develop into a multipoint conference. The MC provides for capability negotiation with all terminals to achieve common levels of communications. It may also control conference resources such as who is multicasting video. The MC does not perform mixing or switching of audio, video and data. 3.36 multipoint processor: The Multipoint Processor (MP) is an H.323 entity on the network which provides for the centralized processing of audio, video and/or data streams in a multipoint conference. The MP provides for the mixing, switching or other processing of media streams under the control of the MC. The MP may process a single media stream or multiple media streams depending on the type of conference supported. Roni --Boundary_(ID_dk9QpDwcj97TGrBE3wWRfg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi

multipoint control unit: The = Multipoint Control Unit (MCU) is an endpoint on the network which = provides the capability for three or more terminals and Gateways to = participate in a multipoint conference. It may also connect two = terminals in a point-to-point conference which may later develop into a = multipoint conference. The MCU generally operates in the fashion of an = H.231 MCU; however, an audio processor is not mandatory. The MCU = consists of two parts: a mandatory Multipoint Controller and optional = Multipoint Processors. In the simplest case, an MCU may consist only of = an MC with no MPs. An MCU may also be brought into a conference by the = Gatekeeper without being explicitly called by one of the = endpoints.

3.35      multipoint = controller: The Multipoint Controller (MC) = is an H.323 entity on the network which provides for the control of = three or more terminals participating in a multipoint conference. It may = also connect two terminals in a point-to-point conference which may = later develop into a multipoint conference. The MC provides for = capability negotiation with all terminals to achieve common levels of = communications. It may also control conference resources such as who is = multicasting video. The MC does not perform mixing or switching of = audio, video and data.

3.36      multipoint = processor: The Multipoint Processor (MP) = is an H.323 entity on the network which provides for the centralized = processing of audio, video and/or data streams in a multipoint = conference. The MP provides for the mixing, switching or other = processing of media streams under the control of the MC. The MP may = process a single media stream or multiple media streams depending on the = type of conference supported.

Roni

= --Boundary_(ID_dk9QpDwcj97TGrBE3wWRfg)-- From coverdale@sympatico.ca Thu Jul 28 06:45:56 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCAD21F8B76 for ; Thu, 28 Jul 2011 06:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[AWL=1.774, 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 rHR0Aop84RNE for ; Thu, 28 Jul 2011 06:45:55 -0700 (PDT) Received: from blu0-omc1-s15.blu0.hotmail.com (blu0-omc1-s15.blu0.hotmail.com [65.55.116.26]) by ietfa.amsl.com (Postfix) with ESMTP id 81A9721F8B67 for ; Thu, 28 Jul 2011 06:45:55 -0700 (PDT) Received: from BLU0-SMTP5 ([65.55.116.9]) by blu0-omc1-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 06:45:54 -0700 X-Originating-IP: [130.129.39.34] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([130.129.39.34]) by BLU0-SMTP5.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 06:45:52 -0700 From: Paul Coverdale To: References: In-Reply-To: Date: Thu, 28 Jul 2011 09:45:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxNKF4jVyFZG9R7TkuYRZlPjUybyAAA3Vwg Content-Language: en-us X-OriginalArrivalTime: 28 Jul 2011 13:45:52.0945 (UTC) FILETIME=[AAFC1A10:01CC4D2C] Subject: Re: [clue] Left and right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 13:45:56 -0000 I'm a bit concerned about the inability to come to an agreement on what is left and what is right. Leaving it "to be interpreted in the context of the description where the word occurs" seems bound to result in future confusion. John's proposal is at least a starting point. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >Elwell, John >Sent: Thursday, July 28, 2011 9:15 AM >To: clue@ietf.org >Subject: [clue] Left and right > >I couldn't formulate this comment in time to come to the mic, but has >any thought been given to defining left and right in a particular way, >to be used unless stated otherwise. > >For example, >Left: Unless stated otherwise, on the left from the point of view of an >observer of rendered media. > >John > > > > > >John Elwell >Tel: +44 1908 817801 (office and mobile) >Email: john.elwell@siemens-enterprise.com >http://www.siemens-enterprise.com/uk/ > >Siemens Enterprise Communications Limited. >Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 >0DJ. >Registered No: 5903714, England. > >Siemens Enterprise Communications Limited is a Trademark Licensee of >Siemens AG. > > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From Even.roni@huawei.com Thu Jul 28 06:48:49 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B48021F8BD9 for ; Thu, 28 Jul 2011 06:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 GxWZD+UJnMVJ for ; Thu, 28 Jul 2011 06:48:48 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5C321F8B43 for ; Thu, 28 Jul 2011 06:48:48 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP1009LIQD916@szxga03-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 21:48:45 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LP1004MAQD9K4@szxga03-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 21:48:45 +0800 (CST) Received: from windows8d787f9 (dhcp-17b3.meeting.ietf.org [130.129.23.179]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LP100C9VQD646@szxml12-in.huawei.com> for clue@ietf.org; Thu, 28 Jul 2011 21:48:45 +0800 (CST) Date: Thu, 28 Jul 2011 16:46:01 +0300 From: Roni Even To: clue@ietf.org Message-id: <00bc01cc4d2c$b2ac2e30$18048a90$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_kfKS9jXjGPivcPgenHn9qQ)" Content-language: en-us Thread-index: AcxNLKwutASgC24JSoCnCTGUCpx4GQ== x-cr-hashedpuzzle: AVjm AbLp CZ9N Cfzc DiiK Dtz4 Ewgg FiAZ F0Qi GZN0 Gf9F HGWC HUzs I2D5 JFcp K1eJ; 1; YwBsAHUAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {55B84B38-3AF7-4972-8203-268CC3B714E0}; ZQB2AGUAbgAuAHIAbwBuAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Thu, 28 Jul 2011 13:45:55 GMT;cgBlAG4AZABlAHIAaQBuAGcAIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwA= x-cr-puzzleid: {55B84B38-3AF7-4972-8203-268CC3B714E0} Subject: [clue] rendering requirements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 13:48:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_kfKS9jXjGPivcPgenHn9qQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, My view is that the requirement will be clear once we agree on the layout term. We had the physical layout and the screen layout. Christer requirements were about to be able to advertise and request a screen layout Roni --Boundary_(ID_kfKS9jXjGPivcPgenHn9qQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

My view is that = the requirement will be clear once we agree on the layout = term.

We had the physical layout and = the screen layout.

Christer = requirements were about to be able to advertise and request a screen = layout

Roni

= --Boundary_(ID_kfKS9jXjGPivcPgenHn9qQ)-- From mphmmr@gmail.com Thu Jul 28 07:06:44 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8221F8AD3 for ; Thu, 28 Jul 2011 07:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3ay+NXorizl for ; Thu, 28 Jul 2011 07:06:43 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD5821F876F for ; Thu, 28 Jul 2011 07:06:43 -0700 (PDT) Received: by gxk19 with SMTP id 19so2224064gxk.31 for ; Thu, 28 Jul 2011 07:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=93MlkuIfT55dq0Jqto5WynDOf/NoHElEgyNn6B4aj04=; b=iBWZbxZgB1WxSy3HF18oNP1jnfQCZ2KUaCAWUVTL8cgSAoYLDLdVJmQkLsodbei5dU tie5PJCGfJTEY0VyKg7hIQRyFpBKIzmaL+5TCfPvV4GA8JcPd7ELZj1s/h3uJllB43Yv NlvH+BQEHY2srm/lDMVpEEFkspMOSbLloZHvI= MIME-Version: 1.0 Received: by 10.42.150.132 with SMTP id a4mr17993icw.291.1311862002841; Thu, 28 Jul 2011 07:06:42 -0700 (PDT) Received: by 10.42.171.6 with HTTP; Thu, 28 Jul 2011 07:06:42 -0700 (PDT) In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A61AE802B0C@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A61AE802B0C@CRPMBOXPRD01.polycom.com> Date: Thu, 28 Jul 2011 10:06:42 -0400 Message-ID: From: Michael Hammer To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=90e6ba212373ac793804a921acf3 Cc: "clue@ietf.org" Subject: Re: [clue] Comment on framework - who gives the hint X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:06:44 -0000 --90e6ba212373ac793804a921acf3 Content-Type: text/plain; charset=ISO-8859-1 Mark, Do these preference ratchet down? Meaning that each step must be a subset of the previous indication? Or are they orthogonal and comprehensive? Also, are these indications capabilities of the device, or current preferences that could change during the session? Both up and down? Mike Hammer On Wed, Jul 27, 2011 at 11:43 PM, Duckworth, Mark < Mark.Duckworth@polycom.com> wrote: > I also prefer the first way. It seems to me the receiver's final > preference in making the choice is more important than the sender's > preference. It is the receiver that has to do something useful with the > streams it receives, so it should be the one to make the final choice. > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Elwell, John > > Sent: Wednesday, July 27, 2011 6:13 PM > > To: clue@ietf.org > > Subject: [clue] Comment on framework - who gives the hint > > > > The framework is based on the following general principle: > > - receiver optionally sends hints as to what it would like to receive; > > - sender indicates what it can send; > > - receives selects what it will receive. > > > > Another possibility would be: > > - transmitter optionally sends hints as to what it can send; > > - receiver indicates what it can receive; > > - transmitter selects what it will send. > > > > I don't have any opinion as to which is the better - in fact I tend to > > lean towards the first, but I can't give a reason. But it would be good > > to know if there are specific reasons for going with the first rather > > than the second. > > > > John > > > > > > John Elwell > > Tel: +44 1908 817801 (office and mobile) > > Email: john.elwell@siemens-enterprise.com > > http://www.siemens-enterprise.com/uk/ > > > > Siemens Enterprise Communications Limited. > > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > > 0DJ. > > Registered No: 5903714, England. > > > > Siemens Enterprise Communications Limited is a Trademark Licensee of > > Siemens AG. > > > > > > _______________________________________________ > > 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 > --90e6ba212373ac793804a921acf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Mark,
=A0
Do these preference ratchet down?=A0 Mea= ning that each step must be a subset of the previous indication?
= =A0
Or are they orthogonal and comprehensive?
=A0
=
Also, are these indications capabilities of the device, or current preferen= ces that could change during the session?=A0 Both up and down?
= =A0
Mike Hammer


=A0
On Wed, Jul 27, 2011 at 11:43 PM, Duckworth, Mark &l= t;Mark.Duckworth@polycom.com<= /a>> wrote:
I also prefer the first way. =A0It seems to me= the receiver's final preference in making the choice is more important= than the sender's preference. =A0It is the receiver that has to do som= ething useful with the streams it receives, so it should be the one to make= the final choice.

Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Elwell, John
> Sent: Wednesday, July 27, 2011 6:13 PM
> To: clue@ietf.org
> Subject: [clue] Comment on framework - who gives the hint
>
> The framework is based on the following general principle:
> - receiver optionally sends hints as to what it would like to receive;=
> - sender indicates what it can send;
> - receives selects what it will receive.
>
> Another possibility would be:
> - transmitter optionally sends hints as to what it can send;
> - receiver indicates what it can receive;
> - transmitter selects what it will send.
>
> I don't have any opinion as to which is the better - in fact I ten= d to
> lean towards the first, but I can't give a reason. But it would be= good
> to know if there are specific reasons for going with the first rather<= br> > than the second.
>
> John
>
>
> John Elwell
> Tel: +44= 1908 817801 (office and mobile)
> Email: john.elwe= ll@siemens-enterprise.com
> ht= tp://www.siemens-enterprise.com/uk/
>
> Siemens Enterprise Communications Limited.
> Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15<= br> > 0DJ.
> Registered No: 5903714, England.
>
> Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG.
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--90e6ba212373ac793804a921acf3-- From mphmmr@gmail.com Thu Jul 28 07:11:43 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4050021F8C96 for ; Thu, 28 Jul 2011 07:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80roL4Dko7jf for ; Thu, 28 Jul 2011 07:11:42 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC6821F8C95 for ; Thu, 28 Jul 2011 07:11:42 -0700 (PDT) Received: by gyd5 with SMTP id 5so2226339gyd.31 for ; Thu, 28 Jul 2011 07:11:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kUHXJOLo3LeBKUc99sTu1LbqSMAgrJxV7sLW69jWsw4=; b=p9KqZ+7/pgqOMKgki4o8+U7EVAfWphBOkzAMDU4/2jq+XnVLeeOHy8zBgaVSRPTCOG +nGrVPCIUT+Rri2/vX0iYE3SO4/dvY6VE0BxT7YuCwiF/te4k6DsAhwstyr3ei5anUgc 01tuybyrLizKY3HKoTdImdNVceqmxjOsYTA94= MIME-Version: 1.0 Received: by 10.42.150.132 with SMTP id a4mr22777icw.291.1311862298863; Thu, 28 Jul 2011 07:11:38 -0700 (PDT) Received: by 10.42.171.6 with HTTP; Thu, 28 Jul 2011 07:11:38 -0700 (PDT) In-Reply-To: <002901cc4cdd$29beb830$7d3c2890$%roni@huawei.com> References: <00e201cc4ca8$6e539590$4afac0b0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61AE802B0D@CRPMBOXPRD01.polycom.com> <002901cc4cdd$29beb830$7d3c2890$%roni@huawei.com> Date: Thu, 28 Jul 2011 10:11:38 -0400 Message-ID: From: Michael Hammer To: Roni Even Content-Type: multipart/alternative; boundary=90e6ba2123735169a404a921be40 Cc: clue@ietf.org Subject: Re: [clue] framework - capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 14:11:43 -0000 --90e6ba2123735169a404a921be40 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Does composed mean that selected multiple RTP streams (typically audio) are mixed/combined into a single RTP stream? (Two or more voices appear on one track?) Mike On Thu, Jul 28, 2011 at 12:16 AM, Roni Even wrote: > ** ** > > Mark,**** > > Composed (true/false) does not provide any meaningful information, compos= ed > from what? See my question on the examples in the draft.**** > > ** ** > > How do you know from the attributes that the meaning is what in the comme= nt > you have at the beginning in the following examples.**** > > ** ** > > 4. VC3- (the loudest panel stream), encoding group:EG1, attributes:**= * > * > > purpose=3Dmain;auto-switched:yes**** > > ** ** > > 5. VC4- (the loudest panel stream with PiPs), encoding group:EG1,**** > > attributes: purpose=3Dmain; composed=3Dtrue; auto-switched:yes**** > > ** ** > > 6. VC5- (the zoomed out view of all people in the room), encoding**** > > group:EG1, attributes: purpose=3Dmain;auto-switched:no**** > > ** ** > > ** ** > > VC3 is switched but maybe it is also used some zoom. So what is being > switched?**** > > VC4 =96 composed from what where do I see that it is the loudest panel wi= th > two PiPs and not just the loudest speaker with one PiP?**** > > VC5- how do I know from the attributes that is a zoomed view of all the > people in the room**** > > ** ** > > As for scale**** > > An optional integer valued variable indicating the spatial scale of***= * > > the video capture, for example centimeters for horizontal image**** > > width.**** > > ** ** > > I am not sure what it means, and saying for example is not a definition. > Spatial scale between what?**** > > ** ** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Duckworth, Mark > *Sent:* Thursday, July 28, 2011 6:49 AM > *To:* clue@ietf.org > *Subject:* Re: [clue] framework - capture set**** > > ** ** > > Yes, the attributes =93composed=94 and =93scale=94 can be used to differe= ntiate > between a zoomed out view and a composite view.**** > > ** ** > > I expect the multi view case can be addressed by adding a video capture > attribute to give more information about the relative viewpoints of the > cameras for each video capture.**** > > ** ** > > Mark**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf O= f > *Roni Even > *Sent:* Wednesday, July 27, 2011 5:59 PM > *To:* clue@ietf.org > *Subject:* [clue] framework - capture set**** > > ** ** > > Hi,**** > > The capture set example has (VC4 - zoomed out view of all people in the > room.). Now is there a way to differentiate between zoom out view and > composite view of all cameras to the 3 to 1 screen use case?**** > > ** ** > > How do you see the extension to support multi view is there is no way to > describe the camera view port explicitly?**** > > ** ** > > Roni**** > > ** ** > ** > ------------------------------ > ** > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > --90e6ba2123735169a404a921be40 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Does composed mean that selected multiple RTP streams (typically audio= ) are mixed/combined into a single RTP stream?=A0 (Two or more voices appea= r on one track?)
=A0
Mike

On Thu, Jul 28, 2011 at 12:16 AM, Roni Even <Even.roni@huawei.com> wrote:=

Mark,

Comp= osed (true/false) does not provide any meaningful information, composed fro= m what? See my question on the examples in the draft.<= /p>

=A0<= u>

How do you know from the attributes that the meaning is what in the c= omment you have at the beginning in the following examples.

=A0<= u>

= =A0=A0 4.=A0 VC3- (the loudest panel stream), encoding group:EG1, attribute= s:

=A0=A0=A0=A0=A0=A0= purpose=3Dmain;auto-switched:yes

=A0

=A0=A0 5.=A0 VC4- (the lo= udest panel stream with PiPs), encoding group:EG1,

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

=A0

=A0=A0 6.=A0 VC5- = (the zoomed out view of all people in the room), encoding

=A0=A0=A0= =A0=A0=A0 group:EG1, attributes: purpose=3Dmain;auto-switched:no<= /u>

=A0<= u>

=A0

VC3 is switched but maybe it is also used some zoom.= =A0So what is being switched?

VC4 =96 com= posed from what where do I see that it is the loudest panel with two PiPs a= nd not just the loudest speaker with one PiP?

VC5- how do I know from the attrib= utes that is a zoomed view of all the people in the room

=A0

As for scal= e

=A0=A0 An optional integer valued variable indicating the spatial s= cale of

=A0 =A0the video c= apture, for example centimeters for horizontal image

=A0=A0 width.=

=A0<= u>

I am not sure what it means, and saying for example is not a definiti= on. Spatial scale between what?

=A0<= u>

Roni

=A0

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf= Of Duckworth, Mark
Sent: Thursday, July 28, 2011 6:49 AM
To: clue@ietf.org
Subject: Re:= [clue] framework - capture set

=A0

Yes, the attribute= s =93composed=94 and =93scale=94 can be used to differentiate between a zoo= med out view and a composite view.

=A0<= u>

I expect the multi view case can be addressed by adding a video captu= re attribute to give more information about the relative viewpoints of the = cameras for each video capture.

=A0<= u>

Mark

=A0

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf= Of Roni Even
Sent: Wednesday, July 27, 2011 5:59 PM
To: clue@ietf.org
Subject: [c= lue] framework - capture set

=A0

Hi,

The capture set example has (VC4 - zoomed out vie= w of all people in the room.). Now is there a way to differentiate between = zoom out view and composite view of all cameras to the 3 to 1 screen use ca= se?

=A0

How do you see the extension to support multi view= is there is no way to describe the camera view port explicitly?<= /u>

=A0

Roni<= /u>

=A0


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


--90e6ba2123735169a404a921be40-- From stephen.botzko@gmail.com Thu Jul 28 07:35:53 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA3E21F8C1A for ; Thu, 28 Jul 2011 07:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.36 X-Spam-Level: X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[AWL=0.238, 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 09VKsqbxxo5T for ; Thu, 28 Jul 2011 07:35:52 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 865EE21F8C19 for ; Thu, 28 Jul 2011 07:35:52 -0700 (PDT) Received: by vxi40 with SMTP id 40so2488553vxi.31 for ; Thu, 28 Jul 2011 07:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rkVBVlOzxunyfUaiLkJdS8P1AnkS3SiKUwoWUUKEAYc=; b=mcj+Yvozg82lgleId3Ww1kawWhbO1YRmgeK339Ls5pyO8+UrtGh9oxc6mWhU0EvMVZ r4eDIdGaH+G8uiqbL2hfCfZWe6xfESnD1iXXJGpmgdJZXWR2FRtCuUA0f13R6wwCPavY aLKYwWuUYl1ZQUavaZYU3nNpjH4KU9twW/vKg= MIME-Version: 1.0 Received: by 10.52.21.243 with SMTP id y19mr107675vde.178.1311863747683; Thu, 28 Jul 2011 07:35:47 -0700 (PDT) Received: by 10.52.185.71 with HTTP; Thu, 28 Jul 2011 07:35:47 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 10:35:47 -0400 Message-ID: From: Stephen Botzko To: Paul Coverdale Content-Type: multipart/alternative; boundary=bcaec50164adaca53604a92214a0 Cc: clue@ietf.org Subject: Re: [clue] Left and right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:35:53 -0000 --bcaec50164adaca53604a92214a0 Content-Type: text/plain; charset=ISO-8859-1 With this approach every usage of left/right then needs to explicitly state where the observer is. So I am not sure it is really any improvement from Stephan's approach, since the location of the observer needs to be in context in any event. Stephen Botzko On Thu, Jul 28, 2011 at 9:45 AM, Paul Coverdale wrote: > I'm a bit concerned about the inability to come to an agreement on what is > left and what is right. Leaving it "to be interpreted in the context of the > description where > the word occurs" seems bound to result in future confusion. John's proposal > is at least a starting point. > > ...Paul > > >-----Original Message----- > >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > >Elwell, John > >Sent: Thursday, July 28, 2011 9:15 AM > >To: clue@ietf.org > >Subject: [clue] Left and right > > > >I couldn't formulate this comment in time to come to the mic, but has > >any thought been given to defining left and right in a particular way, > >to be used unless stated otherwise. > > > >For example, > >Left: Unless stated otherwise, on the left from the point of view of an > >observer of rendered media. > > > >John > > > > > > > > > > > >John Elwell > >Tel: +44 1908 817801 (office and mobile) > >Email: john.elwell@siemens-enterprise.com > >http://www.siemens-enterprise.com/uk/ > > > >Siemens Enterprise Communications Limited. > >Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > >0DJ. > >Registered No: 5903714, England. > > > >Siemens Enterprise Communications Limited is a Trademark Licensee of > >Siemens AG. > > > > > >_______________________________________________ > >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 > --bcaec50164adaca53604a92214a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With this approach every usage of left/right then needs to explicitly state= where the observer is.

So I am not sure it is really any improvemen= t from Stephan's approach, since the location of the observer needs to = be in context in any event.

Stephen Botzko

On Thu, Jul 28, 2011 a= t 9:45 AM, Paul Coverdale <coverdale@sympatico.ca> wrote:
I'm a bit concerned about the inability to come to an agreement on what= is
left and what is right. Leaving it "to be interpreted in the context o= f the
description where
the word occurs" seems bound to result in future confusion. John's= proposal
is at least a starting point.

...Paul

>-----Original Message-----
>From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
>Elwell, John
>Sent: Thursday, July 28, 2011 9:15 AM
>To: clue@ietf.org
>Subject: [clue] Left and right
>
>I couldn't formulate this comment in time to come to the mic, but h= as
>any thought been given to defining left and right in a particular way,<= br> >to be used unless stated otherwise.
>
>For example,
>Left: Unless stated otherwise, on the left from the point of view of an=
>observer of rendered media.
>
>John
>
>
>
>
>
>John Elwell
>Tel: +44 = 1908 817801 (office and mobile)
>Email: john.elwel= l@siemens-enterprise.com
>htt= p://www.siemens-enterprise.com/uk/
>
>Siemens Enterprise Communications Limited.
>Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 >0DJ.
>Registered No: 5903714, England.
>
>Siemens Enterprise Communications Limited is a Trademark Licensee of >Siemens AG.
>
>
>_______________________________________________
>clue mailing list
>clue@ietf.org
>https://www.ietf.org/mailman/listinfo/clue

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

--bcaec50164adaca53604a92214a0-- From john.elwell@siemens-enterprise.com Thu Jul 28 07:43:36 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7481E21F8C6F for ; Thu, 28 Jul 2011 07:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=-0.953, 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 bOHJuDNqgai9 for ; Thu, 28 Jul 2011 07:43:35 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 777D021F8C65 for ; Thu, 28 Jul 2011 07:43:35 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id DF15923F0400; Thu, 28 Jul 2011 16:43:33 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 28 Jul 2011 16:43:33 +0200 From: "Elwell, John" To: Stephen Botzko , Paul Coverdale Date: Thu, 28 Jul 2011 16:43:31 +0200 Thread-Topic: [clue] Left and right Thread-Index: AcxNM6uVnajLZyEXR6uUQH6gY63hmwAAM2Yg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Left and right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:43:36 -0000 By observer, I meant somebody viewing / listening to the rendered media at = a receiving endpoint. Perhaps there is room for refining the words, but in = principle I think it would be good to have some default definition. John =20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On=20 > Behalf Of Stephen Botzko > Sent: 28 July 2011 15:36 > To: Paul Coverdale > Cc: clue@ietf.org > Subject: Re: [clue] Left and right >=20 > With this approach every usage of left/right then needs to=20 > explicitly state where the observer is. >=20 > So I am not sure it is really any improvement from Stephan's=20 > approach, since the location of the observer needs to be in=20 > context in any event. >=20 > Stephen Botzko >=20 >=20 > On Thu, Jul 28, 2011 at 9:45 AM, Paul Coverdale=20 > wrote: >=20 >=20 > I'm a bit concerned about the inability to come to an=20 > agreement on what is > left and what is right. Leaving it "to be interpreted=20 > in the context of the > description where > the word occurs" seems bound to result in future=20 > confusion. John's proposal > is at least a starting point. > =09 > ...Paul > =09 > >-----Original Message----- > >From: clue-bounces@ietf.org=20 > [mailto:clue-bounces@ietf.org] On Behalf Of > >Elwell, John > >Sent: Thursday, July 28, 2011 9:15 AM > >To: clue@ietf.org > >Subject: [clue] Left and right > =09 > > > >I couldn't formulate this comment in time to come to=20 > the mic, but has > >any thought been given to defining left and right in a=20 > particular way, > >to be used unless stated otherwise. > > > >For example, > >Left: Unless stated otherwise, on the left from the=20 > point of view of an > >observer of rendered media. > > > >John > > > > > > > > > > > >John Elwell > >Tel: +44 1908 817801 =20 > (office and mobile) > >Email: john.elwell@siemens-enterprise.com > >http://www.siemens-enterprise.com/uk/ > > > >Siemens Enterprise Communications Limited. > >Registered office: Brickhill Street, Willen Lake,=20 > Milton Keynes, MK15 > >0DJ. > >Registered No: 5903714, England. > > > >Siemens Enterprise Communications Limited is a=20 > Trademark Licensee of > >Siemens AG. > > > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > =09 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =09 >=20 >=20 > = From allyn@cisco.com Thu Jul 28 07:43:46 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5491221F8C65 for ; Thu, 28 Jul 2011 07:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=-0.718, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 MxtqsnZckRYP for ; Thu, 28 Jul 2011 07:43:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C11CE21F8C77 for ; Thu, 28 Jul 2011 07:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=14958; q=dns/txt; s=iport; t=1311864223; x=1313073823; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=2g7HNaQDTW6E/fz/X1kAHPA6Y2fpNjpyDDDO/Oj01ZQ=; b=FpaWYxMnvsFU3uHgUMtI3CDVgxS21eHB8fIzNH2KF/jyM7tYJuPX8KNf g9dkUZmRSqdZJwvgTLaxj/9RMKYL+/16NWp4+N3CM4o44zoHiW/wjpppe RYRTsZbohVYwqCiNJ7CPM+JDXGo8Y7B6k53E8Y5nYeVXGkmlZF5oYSuqx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuEAAGZ1MU6rRDoI/2dsb2JhbAA0AQEBAQMBAQERAQwSA0QLDAUCAQkOAwQBAQsGIwEGARMYIw4IAQEFFwwbgjaVLI9Pd4kApDGeV4ViXwSHWZAwi3Q X-IronPort-AV: E=Sophos;i="4.67,282,1309737600"; d="scan'208,217";a="7402133" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jul 2011 14:43:42 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6SEhgVP008938; Thu, 28 Jul 2011 14:43:42 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Jul 2011 07:43:42 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC4D34.BEC8DE2E" Date: Thu, 28 Jul 2011 07:43:35 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC0514E3C3@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] Comment on framework - who gives the hint Thread-Index: AcxNL5pi32t7vQ1TSxa8zFFEzHq6WgABD83Q References: <44C6B6B2D0CF424AA90B6055548D7A61AE802B0C@CRPMBOXPRD01.polycom.com> From: "Allyn Romanow (allyn)" To: "Michael Hammer" , "Duckworth, Mark" X-OriginalArrivalTime: 28 Jul 2011 14:43:42.0585 (UTC) FILETIME=[BF0D2690:01CC4D34] Cc: clue@ietf.org Subject: Re: [clue] Comment on framework - who gives the hint X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:43:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC4D34.BEC8DE2E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See inline =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Michael Hammer Sent: Thursday, July 28, 2011 7:07 AM To: Duckworth, Mark Cc: clue@ietf.org Subject: Re: [clue] Comment on framework - who gives the hint =20 Mark, =20 Do these preference ratchet down? Meaning that each step must be a subset of the previous indication? The consumer says whatever it wants about itself. The provider states it's capabilities. It may choose which it in light of what it knows about the consumer.=20 So these 2 messages are not derived from each other. The consumer chooses from the advertised capabilities. So the third message is chosen from what is listed in the second =20 Or are they orthogonal and comprehensive? =20 Also, are these indications capabilities of the device, or current preferences that could change during the session? Both up and down? =20 These indications can be changed throughout the call, as conditions change. Some of the exchanged info relates to device, other to network conditions, other to events that occur. The slides for the preso in CLUE enumerate more the inputs to the messages. Mike Hammer =20 On Wed, Jul 27, 2011 at 11:43 PM, Duckworth, Mark wrote: I also prefer the first way. It seems to me the receiver's final preference in making the choice is more important than the sender's preference. It is the receiver that has to do something useful with the streams it receives, so it should be the one to make the final choice. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Elwell, John > Sent: Wednesday, July 27, 2011 6:13 PM > To: clue@ietf.org > Subject: [clue] Comment on framework - who gives the hint > > The framework is based on the following general principle: > - receiver optionally sends hints as to what it would like to receive; > - sender indicates what it can send; > - receives selects what it will receive. > > Another possibility would be: > - transmitter optionally sends hints as to what it can send; > - receiver indicates what it can receive; > - transmitter selects what it will send. > > I don't have any opinion as to which is the better - in fact I tend to > lean towards the first, but I can't give a reason. But it would be good > to know if there are specific reasons for going with the first rather > than the second. > > John > > > John Elwell > Tel: +44 1908 817801 (office and mobile) > Email: john.elwell@siemens-enterprise.com > http://www.siemens-enterprise.com/uk/ > > Siemens Enterprise Communications Limited. > Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 > 0DJ. > Registered No: 5903714, England. > > Siemens Enterprise Communications Limited is a Trademark Licensee of > Siemens AG. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 ------_=_NextPart_001_01CC4D34.BEC8DE2E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See inline

 

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Michael Hammer
Sent: Thursday, July 28, 2011 7:07 AM
To: Duckworth, Mark
Cc: clue@ietf.org
Subject: Re: [clue] Comment on framework - who gives the = hint

 

Mark,

 

Do these preference ratchet down?  Meaning = that each step must be a subset of the previous indication?

The consumer says whatever it wants about = itself.

The provider states it’s capabilities. It may = choose which it in light of what it knows about the consumer.

So these 2 messages are not derived from each = other.

The consumer chooses from the advertised = capabilities.

So the third message is chosen from what is listed in the = second

 

Or are they orthogonal and = comprehensive?

 

Also, are these indications capabilities of the = device, or current preferences that could change during the session?  Both up = and down?

 

These indications can be changed throughout the call, as = conditions change.

Some of the exchanged info relates to device, other to = network conditions, other to events that occur.

The slides for the preso in CLUE enumerate more the = inputs to the messages.

Mike Hammer



 

On Wed, Jul 27, 2011 at 11:43 PM, Duckworth, Mark = <Mark.Duckworth@polycom.com= > wrote:

I also prefer the first way.  It seems to me = the receiver's final preference in making the choice is more important than = the sender's preference.  It is the receiver that has to do something = useful with the streams it receives, so it should be the one to make the final = choice.

Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Elwell, John
> Sent: Wednesday, July 27, 2011 6:13 PM
> To: clue@ietf.org
> Subject: [clue] Comment on framework - who gives the hint
>
> The framework is based on the following general principle:
> - receiver optionally sends hints as to what it would like to = receive;
> - sender indicates what it can send;
> - receives selects what it will receive.
>
> Another possibility would be:
> - transmitter optionally sends hints as to what it can send;
> - receiver indicates what it can receive;
> - transmitter selects what it will send.
>
> I don't have any opinion as to which is the better - in fact I tend = to
> lean towards the first, but I can't give a reason. But it would be = good
> to know if there are specific reasons for going with the first = rather
> than the second.
>
> John
>
>
> John Elwell
> Tel: +44 1908 817801 = (office and mobile)
> Email: john.elwell@siemens-en= terprise.com
> http://www.siemens-enterprise.com/uk/
>
> Siemens Enterprise Communications Limited.
> Registered office: Brickhill Street, Willen Lake, Milton Keynes, = MK15
> 0DJ.
> Registered No: 5903714, England.
>
> Siemens Enterprise Communications Limited is a Trademark Licensee = of
> Siemens AG.
>
>
> _______________________________________________
> 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

 

------_=_NextPart_001_01CC4D34.BEC8DE2E-- From stephen.botzko@gmail.com Thu Jul 28 07:49:09 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9121F8CB6 for ; Thu, 28 Jul 2011 07:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, 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 Af5SjP3cc-AY for ; Thu, 28 Jul 2011 07:49:08 -0700 (PDT) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4747521F8CB4 for ; Thu, 28 Jul 2011 07:49:08 -0700 (PDT) Received: by vws18 with SMTP id 18so3797924vws.27 for ; Thu, 28 Jul 2011 07:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iQbmIyB4pM/WIeuEl1s7wPZ2iXadQrfF4/Y1t6pTmrA=; b=msBvAV05SI0o7AwwWQdjasmqmNn4/xernC8yzxmHfpKg23vlNjANLOqnvETnJyamix gRr+EVYnDNFXdGG62Tvaw97ANTXhol2NzkC7gKIKry4sQuc9EGDeF0wu4kjirIeLdNBe SgRDUpP69lXbrCZGg+p6Ofl9GoGpx/j9u+WP4= MIME-Version: 1.0 Received: by 10.52.22.201 with SMTP id g9mr100550vdf.331.1311864547442; Thu, 28 Jul 2011 07:49:07 -0700 (PDT) Received: by 10.52.185.71 with HTTP; Thu, 28 Jul 2011 07:49:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jul 2011 10:49:07 -0400 Message-ID: From: Stephen Botzko To: "Elwell, John" Content-Type: multipart/alternative; boundary=20cf307813f857ff2604a922446e Cc: "clue@ietf.org" Subject: Re: [clue] Left and right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 14:49:09 -0000 --20cf307813f857ff2604a922446e Content-Type: text/plain; charset=ISO-8859-1 Ok. But we often need to say stuff like "the media stream that comes from the right camera is best rendered on the left display". The default definition makes it hard to make that kind of statement. Stephen Botzko On Thu, Jul 28, 2011 at 10:43 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > By observer, I meant somebody viewing / listening to the rendered media at > a receiving endpoint. Perhaps there is room for refining the words, but in > principle I think it would be good to have some default definition. > > John > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On > > Behalf Of Stephen Botzko > > Sent: 28 July 2011 15:36 > > To: Paul Coverdale > > Cc: clue@ietf.org > > Subject: Re: [clue] Left and right > > > > With this approach every usage of left/right then needs to > > explicitly state where the observer is. > > > > So I am not sure it is really any improvement from Stephan's > > approach, since the location of the observer needs to be in > > context in any event. > > > > Stephen Botzko > > > > > > On Thu, Jul 28, 2011 at 9:45 AM, Paul Coverdale > > wrote: > > > > > > I'm a bit concerned about the inability to come to an > > agreement on what is > > left and what is right. Leaving it "to be interpreted > > in the context of the > > description where > > the word occurs" seems bound to result in future > > confusion. John's proposal > > is at least a starting point. > > > > ...Paul > > > > >-----Original Message----- > > >From: clue-bounces@ietf.org > > [mailto:clue-bounces@ietf.org] On Behalf Of > > >Elwell, John > > >Sent: Thursday, July 28, 2011 9:15 AM > > >To: clue@ietf.org > > >Subject: [clue] Left and right > > > > > > > >I couldn't formulate this comment in time to come to > > the mic, but has > > >any thought been given to defining left and right in a > > particular way, > > >to be used unless stated otherwise. > > > > > >For example, > > >Left: Unless stated otherwise, on the left from the > > point of view of an > > >observer of rendered media. > > > > > >John > > > > > > > > > > > > > > > > > >John Elwell > > >Tel: +44 1908 817801 > > (office and mobile) > > >Email: john.elwell@siemens-enterprise.com > > >http://www.siemens-enterprise.com/uk/ > > > > > >Siemens Enterprise Communications Limited. > > >Registered office: Brickhill Street, Willen Lake, > > Milton Keynes, MK15 > > >0DJ. > > >Registered No: 5903714, England. > > > > > >Siemens Enterprise Communications Limited is a > > Trademark Licensee of > > >Siemens AG. > > > > > > > > >_______________________________________________ > > >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 > > > > > > > > > --20cf307813f857ff2604a922446e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok.=A0

But we often need to say stuff like "the media stream t= hat comes from the right camera is best rendered on the left display".= =A0 The default definition makes it hard to make that kind of statement.
Stephen Botzko

On Thu, Jul 28, 2011 a= t 10:43 AM, Elwell, John <john.elwell@siemens-enterprise.com>= wrote:
By observer, I meant somebody viewing / lis= tening to the rendered media at a receiving endpoint. Perhaps there is room= for refining the words, but in principle I think it would be good to have = some default definition.

John


> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On
> Behalf Of Stephen Botzko
> Sent: 28 July 2011 15:36
> To: Paul Coverdale
> Cc: clue@ietf.org
> Subject: Re: [clue] Left and right
>
> With this approach every usage of left/right then needs to
> explicitly state where the observer is.
>
> So I am not sure it is really any improvement from Stephan's
> approach, since the location of the observer needs to be in
> context in any event.
>
> Stephen Botzko
>
>
> On Thu, Jul 28, 2011 at 9:45 AM, Paul Coverdale
> <coverdale@sympatico.ca> wrote:
>
>
> =A0 =A0 =A0 I'm a bit concerned about the inability to come to an<= br> > agreement on what is
> =A0 =A0 =A0 left and what is right. Leaving it "to be interpreted=
> in the context of the
> =A0 =A0 =A0 description where
> =A0 =A0 =A0 the word occurs" seems bound to result in future
> confusion. John's proposal
> =A0 =A0 =A0 is at least a starting point.
>
> =A0 =A0 =A0 ...Paul
>
> =A0 =A0 =A0 >-----Original Message-----
> =A0 =A0 =A0 >From: clue-bo= unces@ietf.org
> [mailto:clue-bounces@ietf.org= ] On Behalf Of
> =A0 =A0 =A0 >Elwell, John
> =A0 =A0 =A0 >Sent: Thursday, July 28, 2011 9:15 AM
> =A0 =A0 =A0 >To: clue@ietf.org=
> =A0 =A0 =A0 >Subject: [clue] Left and right
>
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >I couldn't formulate this comment in time to come = to
> the mic, but has
> =A0 =A0 =A0 >any thought been given to defining left and right in a=
> particular way,
> =A0 =A0 =A0 >to be used unless stated otherwise.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >For example,
> =A0 =A0 =A0 >Left: Unless stated otherwise, on the left from the > point of view of an
> =A0 =A0 =A0 >observer of rendered media.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >John
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >John Elwell
> =A0 =A0 =A0 >Tel: +44 1908 817801 <tel:%2B44%201908%20817801&= gt;
> (office and mobile)
> =A0 =A0 =A0 >Email: john.elwell@siemens-enterprise.com
> =A0 =A0 =A0 >http://www.siemens-enterprise.com/uk/
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >Siemens Enterprise Communications Limited.
> =A0 =A0 =A0 >Registered office: Brickhill Street, Willen Lake,
> Milton Keynes, MK15
> =A0 =A0 =A0 >0DJ.
> =A0 =A0 =A0 >Registered No: 5903714, England.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >Siemens Enterprise Communications Limited is a
> Trademark Licensee of
> =A0 =A0 =A0 >Siemens AG.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >_______________________________________________
> =A0 =A0 =A0 >clue mailing list
> =A0 =A0 =A0 >clue@ietf.org
> =A0 =A0 =A0 >https://www.ietf.org/mailman/listinfo/clue
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 clue mailing list
> =A0 =A0 =A0 clue@ietf.org
> =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/clue
>
>
>
>

--20cf307813f857ff2604a922446e-- From Mark.Duckworth@polycom.com Thu Jul 28 08:29:40 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103BB21F8B1E for ; Thu, 28 Jul 2011 08:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 3ODfAsJzOhDx for ; Thu, 28 Jul 2011 08:29:38 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 0B86E21F886A for ; Thu, 28 Jul 2011 08:29:36 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Thu, 28 Jul 2011 08:29:36 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 28 Jul 2011 08:29:33 -0700 Thread-Topic: [clue] Left and right Thread-Index: AcxNNZACy4u/RpOIQLGc9KSJiB+wVgABSNiQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802CA4@CRPMBOXPRD01.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61AE802CA4CRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] Left and right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 15:29:40 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802CA4CRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like John's definition. For Steve's concern, I always call that the right camera because it is the = right camera from the observer's point of view, using definition of observ= er as somebody watching rendered stream coming from the camera. I agree this terminology should be clarified in the framework document. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ste= phen Botzko Sent: Thursday, July 28, 2011 10:49 AM To: Elwell, John Cc: clue@ietf.org Subject: Re: [clue] Left and right Ok. But we often need to say stuff like "the media stream that comes from the r= ight camera is best rendered on the left display". The default definition = makes it hard to make that kind of statement. Stephen Botzko On Thu, Jul 28, 2011 at 10:43 AM, Elwell, John > wrote: By observer, I meant somebody viewing / listening to the rendered media at = a receiving endpoint. Perhaps there is room for refining the words, but in = principle I think it would be good to have some default definition. John > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On > Behalf Of Stephen Botzko > Sent: 28 July 2011 15:36 > To: Paul Coverdale > Cc: clue@ietf.org > Subject: Re: [clue] Left and right > > With this approach every usage of left/right then needs to > explicitly state where the observer is. > > So I am not sure it is really any improvement from Stephan's > approach, since the location of the observer needs to be in > context in any event. > > Stephen Botzko > > > On Thu, Jul 28, 2011 at 9:45 AM, Paul Coverdale > > wrote: > > > I'm a bit concerned about the inability to come to an > agreement on what is > left and what is right. Leaving it "to be interpreted > in the context of the > description where > the word occurs" seems bound to result in future > confusion. John's proposal > is at least a starting point. > > ...Paul > > >-----Original Message----- > >From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On Behalf Of > >Elwell, John > >Sent: Thursday, July 28, 2011 9:15 AM > >To: clue@ietf.org > >Subject: [clue] Left and right > > > > >I couldn't formulate this comment in time to come to > the mic, but has > >any thought been given to defining left and right in a > particular way, > >to be used unless stated otherwise. > > > >For example, > >Left: Unless stated otherwise, on the left from the > point of view of an > >observer of rendered media. > > > >John > > > > > > > > > > > >John Elwell > >Tel: +44 1908 817801 > (office and mobile) > >Email: john.elwell@siemens-enterprise.com > >http://www.siemens-enterprise.com/uk/ > > > >Siemens Enterprise Communications Limited. > >Registered office: Brickhill Street, Willen Lake, > Milton Keynes, MK15 > >0DJ. > >Registered No: 5903714, England. > > > >Siemens Enterprise Communications Limited is a > Trademark Licensee of > >Siemens AG. > > > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802CA4CRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I like Jo= hn’s definition.

Fo= r Steve’s concern, I always call that the right camera because it is = the right camera from the observer’s point of view,  using defin= ition of observer as somebody watching rendered stream coming from the came= ra.

 

I agree this terminology should be clarif= ied in the framework document.

 

Mark

 

=

From: clue-bounces@ietf.org [mailto:clue-b= ounces@ietf.org] On Behalf Of Stephen Botzko
Sent: Thursda= y, July 28, 2011 10:49 AM
To: Elwell, John
Cc: clue@iet= f.org
Subject: Re: [clue] Left and right

 

Ok. 

But we often need to say stuf= f like "the media stream that comes from the right camera is best rend= ered on the left display".  The default definition makes it hard = to make that kind of statement.

Stephen Botzko

<= p class=3DMsoNormal>On Thu, Jul 28, 2011 at 10:43 AM, Elwell, John <john.elwell@siemens-enter= prise.com> wrote:

By observer, I = meant somebody viewing / listening to the rendered media at a receiving end= point. Perhaps there is room for refining the words, but in principle I thi= nk it would be good to have some default definition.

John=



> -----Original Message-----
&g= t; From: clue-bounces@ietf.org= [mailto:clue-bounces@ietf.org= ] On

> Behalf Of Stephen Botzko=
> Sent: 28 July 2011 15:36
> To: Paul Coverdale
> Cc: clue@ietf.org
> Subject: Re: [clue= ] Left and right

>
> = With this approach every usage of left/right then needs to
> explicit= ly state where the observer is.
>
> So I am not sure it is real= ly any improvement from Stephan's
> approach, since the location of t= he observer needs to be in
> context in any event.
>
> St= ephen Botzko
>
>
> On Thu, Jul 28, 2011 at 9:45 AM, Paul = Coverdale
> <coverdale@s= ympatico.ca> wrote:
>
>
>       I'm= a bit concerned about the inability to come to an
> agreement on wha= t is
>       left and what is right. Leaving it "= to be interpreted
> in the context of the
>      = ; description where
>       the word occurs" seem= s bound to result in future
> confusion. John's proposal
> &nbs= p;     is at least a starting point.
>
>    = ;   ...Paul
>
>       >-----Original Mes= sage-----
>       >From: clue-bounces@ietf.org
> [mailto:clue-bounces@ietf.org] On Behalf Of
> &nbs= p;     >Elwell, John
>       >Sent: Th= ursday, July 28, 2011 9:15 AM
>       >To: clue@ietf.org
>       &g= t;Subject: [clue] Left and right
>
>       ><= br>>       >I couldn't formulate this comment in time = to come to
> the mic, but has
>       >any th= ought been given to defining left and right in a
> particular way,>       >to be used unless stated otherwise.
> =       >
>       >For example,
= >       >Left: Unless stated otherwise, on the left fr= om the
> point of view of an
>       >observe= r of rendered media.
>       >
>    = ;   >John
>       >
>     &= nbsp; >
>       >
>       &= gt;
>       >
>       >John= Elwell

>     &= nbsp; >Tel: +44 1908 817801 &l= t;tel:%2B44%201908%20817801>

> (office and mobile)
>       >Email: john.elwell@siemens-enterpri= se.com
>       >http://www.siemens-enterprise.com/uk/<= /a>
>       >
>       >Siem= ens Enterprise Communications Limited.
>       >Reg= istered office: Brickhill Street, Willen Lake,
> Milton Keynes, MK15<= br>>       >0DJ.
>       >Regi= stered No: 5903714, England.
>       >
> &nbs= p;     >Siemens Enterprise Communications Limited is a
>= Trademark Licensee of
>       >Siemens AG.
>=       >
>       >
>  =     >_______________________________________________
> =       >clue mailing list
>       >= ;clue@ietf.org
>     &= nbsp; >https://www.ietf.org/mailman/listinfo/clue
>
> &nbs= p;     _______________________________________________
> &n= bsp;     clue mailing list
>       clue@ietf.org
>       http= s://www.ietf.org/mailman/listinfo/clue
>
>
>
> =

 

=
= --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802CA4CRPMBOXPRD01pol_-- From Mark.Duckworth@polycom.com Thu Jul 28 12:58:51 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE88311E8168 for ; Thu, 28 Jul 2011 12:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 0ixExJGm3rvF for ; Thu, 28 Jul 2011 12:58:47 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 7794A21F8A80 for ; Thu, 28 Jul 2011 12:58:45 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by Crpehubprd01.polycom.com ([fe80::27:216a:613a:350c%13]) with mapi; Thu, 28 Jul 2011 12:58:44 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 28 Jul 2011 12:58:42 -0700 Thread-Topic: [clue] Left and right Thread-Index: AcxNO3aRBkjm1D9nRYWQvY2D5My98gAJRCAA Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802E8D@CRPMBOXPRD01.polycom.com> References: <44C6B6B2D0CF424AA90B6055548D7A61AE802CA4@CRPMBOXPRD01.polycom.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61AE802E8DCRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] Left and right X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 19:58:51 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802E8DCRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, I agree the authors need to make it clear, for whatever the frame of r= eference is in a particular context. Mark From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: Thursday, July 28, 2011 11:32 AM To: Duckworth, Mark Subject: Re: [clue] Left and right It is better to give the authors the job of adequately describing the frame= of reference. Steve On Thu, Jul 28, 2011 at 11:29 AM, Duckworth, Mark > wrote: I like John's definition. For Steve's concern, I always call that the right camera because it is the = right camera from the observer's point of view, using definition of observ= er as somebody watching rendered stream coming from the camera. I agree this terminology should be clarified in the framework document. Mark From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Stephen Botzko Sent: Thursday, July 28, 2011 10:49 AM To: Elwell, John Cc: clue@ietf.org Subject: Re: [clue] Left and right Ok. But we often need to say stuff like "the media stream that comes from the r= ight camera is best rendered on the left display". The default definition = makes it hard to make that kind of statement. Stephen Botzko On Thu, Jul 28, 2011 at 10:43 AM, Elwell, John > wrote: By observer, I meant somebody viewing / listening to the rendered media at = a receiving endpoint. Perhaps there is room for refining the words, but in = principle I think it would be good to have some default definition. John > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bo= unces@ietf.org] On > Behalf Of Stephen Botzko > Sent: 28 July 2011 15:36 > To: Paul Coverdale > Cc: clue@ietf.org > Subject: Re: [clue] Left and right > > With this approach every usage of left/right then needs to > explicitly state where the observer is. > > So I am not sure it is really any improvement from Stephan's > approach, since the location of the observer needs to be in > context in any event. > > Stephen Botzko > > > On Thu, Jul 28, 2011 at 9:45 AM, Paul Coverdale > > wrote: > > > I'm a bit concerned about the inability to come to an > agreement on what is > left and what is right. Leaving it "to be interpreted > in the context of the > description where > the word occurs" seems bound to result in future > confusion. John's proposal > is at least a starting point. > > ...Paul > > >-----Original Message----- > >From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On Behalf Of > >Elwell, John > >Sent: Thursday, July 28, 2011 9:15 AM > >To: clue@ietf.org > >Subject: [clue] Left and right > > > > >I couldn't formulate this comment in time to come to > the mic, but has > >any thought been given to defining left and right in a > particular way, > >to be used unless stated otherwise. > > > >For example, > >Left: Unless stated otherwise, on the left from the > point of view of an > >observer of rendered media. > > > >John > > > > > > > > > > > >John Elwell > >Tel: +44 1908 817801 > (office and mobile) > >Email: john.elwell@siemens-enterprise.com > >http://www.siemens-enterprise.com/uk/ > > > >Siemens Enterprise Communications Limited. > >Registered office: Brickhill Street, Willen Lake, > Milton Keynes, MK15 > >0DJ. > >Registered No: 5903714, England. > > > >Siemens Enterprise Communications Limited is a > Trademark Licensee of > >Siemens AG. > > > > > >_______________________________________________ > >clue mailing list > >clue@ietf.org > >https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802E8DCRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, I ag= ree the authors need to make it clear, for whatever the frame of reference = is in a particular context.

Mark

 

From: Stephen Botzko [ma= ilto:stephen.botzko@gmail.com]
Sent: Thursday, July 28, 2011 11:= 32 AM
To: Duckworth, Mark
Subject: Re: [clue] Left and = right

 

It is better to g= ive the authors the job of adequately describing the frame of reference.
Steve

On Thu, Jul 28, 2011 at = 11:29 AM, Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:

<= span style=3D'font-size:11.0pt;color:#1F497D'>I like John’s definitio= n.

For Steve’s concern, I always call that the right camera because = it is the right camera from the observer’s point of view,  using= definition of observer as somebody watching rendered stream coming from th= e camera.

 

I agree this terminology should be clarified in the framew= ork document.

 

Mark

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Stephe= n Botzko
Sent: Thursday, July 28, 2011 10:49 AM
To: Elw= ell, John


Cc: clue@ietf.org
<= b>Subject: Re: [clue] Left and right

 

Ok. 

But we often n= eed to say stuff like "the media stream that comes from the right came= ra is best rendered on the left display".  The default definition= makes it hard to make that kind of statement.

Stephen Botzko<= /o:p>

On Thu, Jul 28, 2011 at 10:43 AM, Elwell, John <john.e= lwell@siemens-enterprise.com> wrote:

By observe= r, I meant somebody viewing / listening to the rendered media at a receivin= g endpoint. Perhaps there is room for refining the words, but in principle = I think it would be good to have some default definition.

John<= /o:p>



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

> Behalf Of S= tephen Botzko
> Sent: 28 July 2011 15:36
> To: Paul Coverdale> Cc: clue@ietf.org=
> Subject: Re: [clue] Left and right

>
> With this approach every usage of left/right then needs to=
> explicitly state where the observer is.
>
> So I am no= t sure it is really any improvement from Stephan's
> approach, since = the location of the observer needs to be in
> context in any event.>
> Stephen Botzko
>
>
> On Thu, Jul 28, 2011 = at 9:45 AM, Paul Coverdale
> <coverdale@sympatico.ca> wrote:
>
&g= t;
>       I'm a bit concerned about the inability to = come to an
> agreement on what is
>       left a= nd what is right. Leaving it "to be interpreted
> in the context= of the
>       description where
>    = ;   the word occurs" seems bound to result in future
> conf= usion. John's proposal
>       is at least a starting = point.
>
>       ...Paul
>
>   =     >-----Original Message-----
>       &= gt;From: clue-bo= unces@ietf.org
> [mailto:clue-bounces@ietf.org] On Behalf Of
>   &= nbsp;   >Elwell, John
>       >Sent: Thursd= ay, July 28, 2011 9:15 AM
>       >To: clue@ietf.org
>   &nb= sp;   >Subject: [clue] Left and right
>
>    =   >
>       >I couldn't formulate this com= ment in time to come to
> the mic, but has
>     &nbs= p; >any thought been given to defining left and right in a
> parti= cular way,
>       >to be used unless stated otherw= ise.
>       >
>       >For= example,
>       >Left: Unless stated otherwise, o= n the left from the
> point of view of an
>      = ; >observer of rendered media.
>       >
>=       >John
>       >
> &n= bsp;     >
>       >
>   &n= bsp;   >
>       >
>     &n= bsp; >John Elwell

>     =   >Tel: +44= 1908 817801 <tel:%2B44%201908%20817801>

=

> (office and mobile)
>       >Email: john.e= lwell@siemens-enterprise.com
>       >http://www.sie= mens-enterprise.com/uk/
>       >
>  = ;     >Siemens Enterprise Communications Limited.
> &nbs= p;     >Registered office: Brickhill Street, Willen Lake,
&= gt; Milton Keynes, MK15
>       >0DJ.
>  = ;     >Registered No: 5903714, England.
>     =   >
>       >Siemens Enterprise Communicati= ons Limited is a
> Trademark Licensee of
>      = >Siemens AG.
>       >
>     &n= bsp; >
>       >________________________________= _______________
>       >clue mailing list
> =       >clue@ietf.org
>       >https://www.ietf.org/mail= man/listinfo/clue
>
>       ________________= _______________________________
>       clue mailing l= ist
>       clue@ietf.org
>       https://www.ietf.org/= mailman/listinfo/clue
>
>
>
>

 

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>
____________________= ___________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue=

 

= = --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802E8DCRPMBOXPRD01pol_-- From Mark.Duckworth@polycom.com Thu Jul 28 14:05:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811B11E80B4 for ; Thu, 28 Jul 2011 14:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 4Tf5hz9IGIbU for ; Thu, 28 Jul 2011 14:05:57 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F24DF11E8081 for ; Thu, 28 Jul 2011 14:05:54 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Thu, 28 Jul 2011 14:05:53 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 28 Jul 2011 14:05:52 -0700 Thread-Topic: [clue] framework - capture set Thread-Index: AcxMqGvImh9NvgMbTN6/eAlpxjefCAAMEFgAAACGetAAI5dFEA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802F09@CRPMBOXPRD01.polycom.com> References: <00e201cc4ca8$6e539590$4afac0b0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61AE802B0D@CRPMBOXPRD01.polycom.com> <002901cc4cdd$29beb830$7d3c2890$%roni@huawei.com> In-Reply-To: <002901cc4cdd$29beb830$7d3c2890$%roni@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F09CRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] framework - capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:05:59 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F09CRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Roni, you are correct those attributes and the framework do not specify the= video captures as precisely as that. We thought that level of detail in s= pecifying what specifically is shown in video captures was not needed. But= if it is needed, I think that type of detail can be added to the framework= by adding some new attributes. The scale attribute is not well specified in the document, we need a more p= recise definition of what that attribute means. The intent is to indicate = the size of the field of view shown in the video capture. Not the angle of= the field of view of a camera, but the width of the image at the plane whe= re the primary subject is located, such as the first row of people in a tel= epresence room. Mark From: Roni Even [mailto:Even.roni@huawei.com] Sent: Thursday, July 28, 2011 12:17 AM To: Duckworth, Mark; clue@ietf.org Subject: RE: [clue] framework - capture set Mark, Composed (true/false) does not provide any meaningful information, composed= from what? See my question on the examples in the draft. How do you know from the attributes that the meaning is what in the comment= you have at the beginning in the following examples. 4. VC3- (the loudest panel stream), encoding group:EG1, attributes: purpose=3Dmain;auto-switched:yes 5. VC4- (the loudest panel stream with PiPs), encoding group:EG1, attributes: purpose=3Dmain; composed=3Dtrue; auto-switched:yes 6. VC5- (the zoomed out view of all people in the room), encoding group:EG1, attributes: purpose=3Dmain;auto-switched:no VC3 is switched but maybe it is also used some zoom. So what is being swit= ched? VC4 - composed from what where do I see that it is the loudest panel with t= wo PiPs and not just the loudest speaker with one PiP? VC5- how do I know from the attributes that is a zoomed view of all the peo= ple in the room As for scale An optional integer valued variable indicating the spatial scale of the video capture, for example centimeters for horizontal image width. I am not sure what it means, and saying for example is not a definition. Sp= atial scale between what? Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Thursday, July 28, 2011 6:49 AM To: clue@ietf.org Subject: Re: [clue] framework - capture set Yes, the attributes "composed" and "scale" can be used to differentiate bet= ween a zoomed out view and a composite view. I expect the multi view case can be addressed by adding a video capture att= ribute to give more information about the relative viewpoints of the camera= s for each video capture. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ron= i Even Sent: Wednesday, July 27, 2011 5:59 PM To: clue@ietf.org Subject: [clue] framework - capture set Hi, The capture set example has (VC4 - zoomed out view of all people in the roo= m.). Now is there a way to differentiate between zoom out view and composit= e view of all cameras to the 3 to 1 screen use case? How do you see the extension to support multi view is there is no way to de= scribe the camera view port explicitly? Roni --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F09CRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Roni, you are correct those attributes and the framework do n= ot specify the video captures as precisely as that.  We thought that l= evel of detail in specifying what specifically is shown in video captures w= as not needed.  But if it is needed, I think that type of detail can b= e added to the framework by adding some new attributes.

 

The scale attribut= e is not well specified in the document, we need a more precise definition = of what that attribute means.  The intent is to indicate the size of t= he field of view shown in the video capture.  Not the angle of the fie= ld of view of a camera, but the width of the image at the plane where the p= rimary subject is located, such as the first row of people in a telepresenc= e room.

 

Mark

 

From: Roni Even [mailto:Even.roni@huawei.com]
Sent: Thursday= , July 28, 2011 12:17 AM
To: Duckworth, Mark; clue@ietf.org
Subject: RE: [clue] framework - capture set

 

Mark,

Composed (true/false) does not provide any mean= ingful information, composed from what? See my question on the examples in = the draft.

 

How do you know from the attributes that the meaning is what in= the comment you have at the beginning in the following examples.

 <= /o:p>

   4.  VC3- (the loudest panel stream), encoding grou= p:EG1, attributes:

       purpose= =3Dmain;auto-switched:yes

 

   5.&n= bsp; VC4- (the loudest panel stream with PiPs), encoding group:EG1,

       attributes: purpose=3Dmain; compo= sed=3Dtrue; auto-switched:yes

=  

   6= .  VC5- (the zoomed out view of all people in the room), encoding=

       group:EG1, attributes: purpose= =3Dmain;auto-switched:no

 

 

= VC3 is switched but maybe it is also used som= e zoom.  So what is being switched?

VC4 – composed from what where = do I see that it is the loudest panel with two PiPs and not just the loudes= t speaker with one PiP?

VC5- how do I know from the attributes that is a zoome= d view of all the people in the room

 

As for scale

  = An optional integer valued variable indicating the spatial scale of

   the video capture, for example centimeters for horizonta= l image

   width.

 

I am not sure what it means, and= saying for example is not a definition. Spatial scale between what?

&nbs= p;

Roni<= o:p>

 

From:<= /b> clue= -bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckwo= rth, Mark
Sent: Thursday, July 28, 2011 6:49 AM
To: clu= e@ietf.org
Subject: Re: [clue] framework - capture set=

 

Yes, the attributes “compo= sed” and “scale” can be used to differentiate between a z= oomed out view and a composite view.

 

I expect the multi view case can be a= ddressed by adding a video capture attribute to give more information about= the relative viewpoints of the cameras for each video capture.<= /span>

 

Mark<= /o:p>

&nb= sp;

From: clue-boun= ces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Roni EvenSent: Wednesday, July 27, 2011 5:59 PM
To: clue@ietf.org=
Subject: [clue] framework - capture set

 

Hi,=

The capture set example has (VC4 - zoomed o= ut view of all people in the room.). Now is there a way to differentiate be= tween zoom out view and composite view of all cameras to the 3 to 1 screen = use case?

 

How do you see the extension to support multi view is the= re is no way to describe the camera view port explicitly?=

 

Roni

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F09CRPMBOXPRD01pol_-- From Mark.Duckworth@polycom.com Thu Jul 28 14:07:51 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E7111E80FB for ; Thu, 28 Jul 2011 14:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, 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 TbQFy-xF8KaY for ; Thu, 28 Jul 2011 14:07:49 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6C38611E80B4 for ; Thu, 28 Jul 2011 14:07:47 -0700 (PDT) Received: from Crpmboxprd01.polycom.com ([fe80::e001:c7b0:91a1:9443]) by crpehubprd02.polycom.com ([fe80::1c3e:2e7c:4b4f:14fd%10]) with mapi; Thu, 28 Jul 2011 14:07:47 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 28 Jul 2011 14:07:45 -0700 Thread-Topic: [clue] framework - capture set Thread-Index: AcxNMEclmaED0zgzQWuhnlMSk5cD5gAOe/7w Message-ID: <44C6B6B2D0CF424AA90B6055548D7A61AE802F0D@CRPMBOXPRD01.polycom.com> References: <00e201cc4ca8$6e539590$4afac0b0$%roni@huawei.com> <44C6B6B2D0CF424AA90B6055548D7A61AE802B0D@CRPMBOXPRD01.polycom.com> <002901cc4cdd$29beb830$7d3c2890$%roni@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: multipart/alternative; boundary="_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F0DCRPMBOXPRD01pol_" MIME-Version: 1.0 Subject: Re: [clue] framework - capture set X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2011 21:07:51 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F0DCRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That was the intent of the "mixed" attribute for audio. "composed" was meant to be applied to video, but they are conceptually the = same sort of thing. Mark From: Michael Hammer [mailto:mphmmr@gmail.com] Sent: Thursday, July 28, 2011 10:12 AM To: Roni Even Cc: Duckworth, Mark; clue@ietf.org Subject: Re: [clue] framework - capture set Does composed mean that selected multiple RTP streams (typically audio) are= mixed/combined into a single RTP stream? (Two or more voices appear on on= e track?) Mike On Thu, Jul 28, 2011 at 12:16 AM, Roni Even > wrote: Mark, Composed (true/false) does not provide any meaningful information, composed= from what? See my question on the examples in the draft. How do you know from the attributes that the meaning is what in the comment= you have at the beginning in the following examples. 4. VC3- (the loudest panel stream), encoding group:EG1, attributes: purpose=3Dmain;auto-switched:yes 5. VC4- (the loudest panel stream with PiPs), encoding group:EG1, attributes: purpose=3Dmain; composed=3Dtrue; auto-switched:yes 6. VC5- (the zoomed out view of all people in the room), encoding group:EG1, attributes: purpose=3Dmain;auto-switched:no VC3 is switched but maybe it is also used some zoom. So what is being swit= ched? VC4 - composed from what where do I see that it is the loudest panel with t= wo PiPs and not just the loudest speaker with one PiP? VC5- how do I know from the attributes that is a zoomed view of all the peo= ple in the room As for scale An optional integer valued variable indicating the spatial scale of the video capture, for example centimeters for horizontal image width. I am not sure what it means, and saying for example is not a definition. Sp= atial scale between what? Roni From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Duckworth, Mark Sent: Thursday, July 28, 2011 6:49 AM To: clue@ietf.org Subject: Re: [clue] framework - capture set Yes, the attributes "composed" and "scale" can be used to differentiate bet= ween a zoomed out view and a composite view. I expect the multi view case can be addressed by adding a video capture att= ribute to give more information about the relative viewpoints of the camera= s for each video capture. Mark From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, July 27, 2011 5:59 PM To: clue@ietf.org Subject: [clue] framework - capture set Hi, The capture set example has (VC4 - zoomed out view of all people in the roo= m.). Now is there a way to differentiate between zoom out view and composit= e view of all cameras to the 3 to 1 screen use case? How do you see the extension to support multi view is there is no way to de= scribe the camera view port explicitly? Roni ________________________________ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F0DCRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That was = the intent of the “mixed” attribute  for audio.=

“composed” was meant to = be applied to video, but they are conceptually the same sort of thing.=

Mark

 

<= p class=3DMsoNormal>From: Michael Hammer [mailto:mphmmr@gmail.com]
Sen= t: Thursday, July 28, 2011 10:12 AM
To: Roni Even
Cc: Duckworth, Mark; clue@ietf.org
Subject: Re: [clue] framework -= capture set

&nb= sp;

Does composed mean that selected mul= tiple RTP streams (typically audio) are mixed/combined into a single RTP st= ream?  (Two or more voices appear on one track?)

<= div>

 

Mike

On Thu, Jul 28, 2011 at 12:16 AM, Roni Even <Even.roni@huawei.com> wrote:

Mark,

Composed (true/false) does not provide an= y meaningful information, composed from what? See my question on the exampl= es in the draft.

=  

How do you= know from the attributes that the meaning is what in the comment you have = at the beginning in the following examples.

<= span style=3D'color:#1F497D'> 

   4.  VC3- (the loudest panel st= ream), encoding group:EG1, attributes:

       purpose= =3Dmain;auto-switched:yes

 

   5.  VC4- (the loudest panel stream with Pi= Ps), encoding group:EG1,

       attributes: purpose=3D= main; composed=3Dtrue; auto-switched:yes

 

   6.  VC5- (the zoomed out v= iew of all people in the room), encoding

       group:= EG1, attributes: purpose=3Dmain;auto-switched:no

 

 

VC3 is switched but maybe it is also used some zoom.  So w= hat is being switched?

VC4 – composed from what where do I see that it is the loudest = panel with two PiPs and not just the loudest speaker with one PiP?

VC5- how do I know from t= he attributes that is a zoomed view of all the people in the room

 

As for scale

   An optional integer= valued variable indicating the spatial scale of

   the video capture, for= example centimeters for horizontal image

   width.

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'> 

I am not sure what it means, and saying for examp= le is not a definition. Spatial scale between what?

 

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behal= f Of Duckworth, Mark
Sent: Thursday, July 28, 2011 6:49 AMTo: clue@ietf.or= g
Subject: Re: [clue] framework - capture set

 

Yes, the attributes “composed” and “sc= ale” can be used to differentiate between a zoomed out view and a com= posite view.

&nbs= p;

I expect the m= ulti view case can be addressed by adding a video capture attribute to give= more information about the relative viewpoints of the cameras for each vid= eo capture.

 = ;

Mark

 

From: clue-bounces@ietf.o= rg [mailto:c= lue-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wed= nesday, July 27, 2011 5:59 PM
To: clue@ietf.org
Subject: [clue] framework -= capture set

 

<= p class=3DMsoNormal style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:= auto'>Hi,

The capture set= example has (VC4 - zoomed out view of all people in the room.). Now is the= re a way to differentiate between zoom out view and composite view of all c= ameras to the 3 to 1 screen use case?

 

How do you see the extension to support multi view is there is n= o way to describe the camera view port explicitly?

=  

Roni

 


_________________= ______________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue<= /a>

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A61AE802F0DCRPMBOXPRD01pol_-- From marshall.eubanks@gmail.com Thu Jul 28 16:34:59 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AF411E80C8 for ; Thu, 28 Jul 2011 16:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.145 X-Spam-Level: X-Spam-Status: No, score=-103.145 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=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 D28W5WCyBw-5 for ; Thu, 28 Jul 2011 16:34:58 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFA211E80C3 for ; Thu, 28 Jul 2011 16:34:58 -0700 (PDT) Received: by yxp4 with SMTP id 4so2437495yxp.31 for ; Thu, 28 Jul 2011 16:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=QcPNU8S0yoh3k4TSOzgaG/91AmK/E4Vw4j+D5tk+FyU=; b=uwBBNHp47ri3XKkJdaM5Asnq2JGPTijPVxuUpGj6Xi4AroYkNna4bnAPkTYneC2zQL 21+EQZWhZn74aJCplJgSYsg81BAWLDcFzQMJBNCYi4pjKOrjvXzua2IVj3yRwEsVlG/3 SGVJqSr+QaHQ16mmkOrKjSuarCJDn/NdEZAHI= MIME-Version: 1.0 Received: by 10.150.2.16 with SMTP id 16mr525350ybb.437.1311896098117; Thu, 28 Jul 2011 16:34:58 -0700 (PDT) Received: by 10.151.12.20 with HTTP; Thu, 28 Jul 2011 16:34:58 -0700 (PDT) Date: Thu, 28 Jul 2011 19:34:58 -0400 Message-ID: From: Marshall Eubanks To: clue@ietf.org Content-Type: multipart/alternative; boundary=000e0cd40566e91a1104a9299cc5 Subject: [clue] My notes from Today's CLUE meeting (for the period when I scribed) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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 Jul 2011 23:34:59 -0000 --000e0cd40566e91a1104a9299cc5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable CLUE - 1028 AM July 28 2011 Marshall Eubanks (second scribe) took over from Magnus ------ Allyn Romanow - Clue framework What we are doing here - telepresence deals with multiple streams, while ou= r standards deal with single streams. Challenges - we want something - immediately usable (or at least relatively quickly) - extensible - and simple and practical to implement The Framework clusters around 2 concepts - media capture information that needs to be passed - how the provider figures out what streams to send process - provider provides capabilities - consumer choses from these optimization - before negotiation, the consumer may send info about itself to the provider, so the provider can tailor what it provides. Properties - Media capture - encode groups - simultaneous transmission sets I want to take a minute to set context - any proposed framework was going t= o be difficult to communicate. We thought we should do so in stages and start simple. We would like it if people would focus on the concepts first. ------ Mark Duckworth Media Capture and Attributes A media capture is a source of audio or video media. They can be - media from a camera or a microphone (a capture device) - media from a combination of media devices - or, this could be done remotely. A capture set is a way to group media captures that have some relations Some attributed include things like - is the video auto switched or composed ? - is the audio mixed ? - audio channel format (mono/stereo=85) - what is the spatial scale / image width on video Attributes include a "purpose" - say, main versus presentation I want to introduce a capture scene - imagine a given scene with people - cameras - camera views types include - one camera per screen - merging cameras in some fashion - switched based on voice with a composed PiP etc. Chris - you don't assume that the whole scene is always shown Mark - of course Roni - What about other models ? (lists some) Mark - this is just one example. A capture set is a representation of a group of video capture. It has N "rows." Each row is a capture set. Ordering within the rows important - it'= s how the left to right order is imposed. [big discussion of capture sets and what they mean and how they might work dynamically, which alas I took part so didn't capture] Cullen - when we charted this WG Allyn - we were trying to start with something simple Stephan Botcho - the goal here is to achieve interoperability. Having some approximate idea of adjacency may be more powerful Roni - this talks about a simple architecture Christian ? - we still have a concept of left right ? Stephan Wenger - I am willing to spend work, but I am not willing to let yo= u off the hook when there are requirements that are relevant for me. Mark - Matching audio and video - when they are part of the same capture se= t - that includes time synchronization and spatial relationships Spatial relationships - audio direction should roughly match video directions In the audio, we are calling this audio channel formats - a receiver can ma= p these into its loudspeakers to approximate the spatial relationship, in a way better than just going to mono, but not requiring identical audio formats. Allyn - the point is whether or not the draft deals with everything we need to capture the framework, not whether it deals with all of the details. ------ Andy Pepperell Choosing streams Basic Message flow media stream consumer and media stream provider (of course, typically side each has both) msc communicates with msp msc : consumer capability advertisement msp : media capture advertisement Initial message msc : consumer capability advertisement (AKA "the hint") Physical factors User preferences Software limitations etc. Next (the second message,from msp to msc) is the media capture advertisemen= t from the msp - most recently received consumer capability advertisement - provider fixed parameters, such as the number of cameras - dynamic factors - active speaker, presentation source status, - simultaneous transmission sets, etc. Third message (msc to msp) Stream configure message from the msc based on media capture advertisement consumer fixed characteristics dynamic factors this is the trigger for actual media transfer from the provider question - why not us the terms sender and receiver ? Andy - we thought this was a little different case and that might confuse people. Mark - and, this is not the sending and receiving of media Andy - simultaneous transmission sets suppose that the same camera is a digital zoom of one sub-scene, and also provides the entire scene - that's why you need simultaneous transmission sets Encoding groups - part of the media capture set advertisement by the media stream provider. Each capture has an associated Encoding group structure - within an encoding group, there is a possibility of multiple encode or multiple potential encodes the usual sort of video encode attributed (advertised by the provider to th= e consumer) (these are the usual sorts of stuff, bandwidth, max bandwidth, etc.) Roni - from the consumer side you are talking about screens. You also have to some way of linking encoding group with a specific codec. Marshall Eubanks : So, if something changes in the middle of a session, to change things you will have to have the provider send a new media capture advertisement to the consumer, which will have to then send a new Stream configure message, to get the changed stream. Andy : Yes Marshall : So the consumer will have to be listening to the provider for MCAs at any time? Andy : Yes. Marshall : And, of course, you will need error messages. Andy : Of course. The msc might get it wrong. Meeting ended at 11:30 AM EDT. --000e0cd40566e91a1104a9299cc5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
CLUE - 1028 AM July 28 2011
Marshall Eubanks (second scribe)= =A0
took over from Magnus

------




- extensible
- and simple and practical to implement


provider, so the provider can tailor what it provides.

<= /div>
Properties

- Media capture
- e= ncode groups
- simultaneous transmission sets

I want to take a minute to set context - any proposed framework was go= ing to be difficult to communicate. We thought we should do so in stages an= d start simple. We would like it if people would focus on the concepts firs= t.

------
Mark Duckworth

Media Capture and Attributes

A media capture is = a source of audio or video media.

They can be

- media from a camera or a microphone (a capture device= )

- media from a combination of media devices

- or, this could be done remotely.=A0

A capture set is a way to group media captures that have some re= lations

Some attributed include things like
<= div>
- is the video auto switched or composed ?
- is the audio mixed ?
- audio channel format (mono/stereo=85)
- what is the spatial scale / image width on video

Attributes include a "purpose" - say, main versus presen= tation

I want to introduce a capture scene -=A0

=
imagine a given scene with people - cameras - camera views
=

types include=A0

- one camera = per screen
- merging cameras in some fashion
- switched based on voice = with a composed PiP

etc.

= Chris - you don't assume that the whole scene is always shown

Mark - of course

Roni - What a= bout other models ? (lists some)

Mark - this is ju= st one example.=A0

A capture set is a representati= on of a group of video capture. It has N "rows." Each row is a ca= pture set. Ordering within the rows important - it's how the left to ri= ght order is imposed.

[big discussion of capture sets and what they mean and = how they might work dynamically, which alas I took part so didn't captu= re]

Cullen - when we charted this WG=A0

Allyn - we were trying to start with something simple
<= div>
Stephan Botcho - the goal here is to achieve interoperab= ility. Having some approximate idea of adjacency may be more powerful=A0

Roni - this talks about a simple architecture

Christian ? - we still have a concept of left right ?=A0

Stephan Wenger - I am willing to spend work, but I a= m not willing to let you off the hook when there are requirements that are = relevant for me.=A0

Mark - Matching audio and video - when they are part of= the same capture set - that includes time synchronization and spatial rela= tionships

Spatial relationships - audio direction = should roughly match video directions

In the audio, we are calling this audio channel formats= - a receiver can map these
into its loudspeakers to approximate = the spatial relationship, in a way better than just going to mono, but not = requiring identical audio formats.=A0

Allyn - the point is whether or not the draft deals wit= h everything we need to capture the framework, not whether it deals with al= l of the details.

------
Andy Pepperell<= /div>

Choosing streams

Basic Message= flow

media stream consumer and media stream provi= der

(of course, typically side each has both)

msc communicates with msp

msc = : consumer capability advertisement
msp : media capture advertise= ment

Initial message msc : consumer capability adv= ertisement
(AKA "the hint")

Physical factors
User preferences
Software limitations
etc.

Next (the second message,from msp to msc) is the medi= a capture advertisement from the msp

- most recently received consumer capability advertisem= ent
- provider fixed parameters, such as the number of cameras
- dynamic factors - active speaker, presentation source status,=A0<= /div>
- simultaneous transmission sets, etc.

Third = message (msc to msp)

Stream configure message from= the msc

based on media capture advertisement
consumer fixed characteristics=A0
dynamic factors
=
this is the trigger for actual media transfer from the provi= der

question - why not us the terms sender and rec= eiver ?

Andy - we thought this was a little different case and = that might confuse people.=A0

Mark - and, this is = not the sending and receiving of media

Andy - simu= ltaneous transmission sets=A0

suppose that the same camera is a digital zoom of one s= ub-scene, and also provides the entire scene - that's why you need simu= ltaneous transmission sets

Encoding groups =A0- pa= rt of the media capture set advertisement=A0
by the media stream provider. Each capture has an associated=A0
<= div>
Encoding group structure - within an encoding group, the= re is a possibility of multiple encode or multiple potential encodes

the usual sort of video encode attributed (advertised b= y the provider to the consumer)=A0
(these are the usual sorts of = stuff, bandwidth, max bandwidth, etc.)=A0

Roni - f= rom the consumer side you are talking about screens.=A0

You also have to some way of linking encoding group wit= h a specific codec.

Marshall Eubanks : So, if some= thing changes in the middle of a session, to change things you will have to= have the provider send a new media capture advertisement to the consumer, = which will have to then send a new Stream configure message, to get the cha= nged stream.=A0

Andy : Yes

Marshall : So the c= onsumer will have to be listening to the provider for MCAs at any time?

Andy : Yes.

Marshall : And, = of course, you will need error messages.

Andy : Of course. The msc might get it wrong.

Meeting ended at 11:30 AM EDT.
--000e0cd40566e91a1104a9299cc5-- From ietf@meetecho.com Fri Jul 29 00:13:42 2011 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0088621F86C4 for ; Fri, 29 Jul 2011 00:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.644 X-Spam-Level: X-Spam-Status: No, score=-0.644 tagged_above=-999 required=5 tests=[AWL=0.075, 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 kg+QDROfW0uf for ; Fri, 29 Jul 2011 00:13:41 -0700 (PDT) Received: from smtplqs01.aruba.it (smtplqs-out17.aruba.it [62.149.158.57]) by ietfa.amsl.com (Postfix) with SMTP id 4609821F86BA for ; Fri, 29 Jul 2011 00:13:38 -0700 (PDT) Received: (qmail 16707 invoked by uid 89); 29 Jul 2011 07:13:34 -0000 Received: from unknown (HELO smtpw1.aruba.it) (62.149.128.188) by smtplqs01.aruba.it with SMTP; 29 Jul 2011 07:13:34 -0000 Received: (qmail 30275 invoked by uid 89); 29 Jul 2011 07:13:34 -0000 Received: from unknown (HELO aruba.it) (62.149.158.90) by smtpw1.ad.aruba.it with SMTP; 29 Jul 2011 07:13:34 -0000 Date: Fri, 29 Jul 2011 09:13:33 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: "Meetecho IETF support" To: clue@ietf.org X-XaM3-API-Version: V3(R2) X-SenderIP: 70.81.226.194 X-Spam-Rating: smtpw1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplqs01.aruba.it 1.6.2 0/1000/N Subject: [clue] CLUE recording available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 07:13:42 -0000 Dear all,=0A=0Athe full recording (synchronized video, audio, slides and = jabber room) =0Aof yesterday's CLUE session is available.=0A=0AYou can wa= tch it by either clicking the proper link on the remote participation pag= e (http://www.ietf.org/meeting/81/remote-participation.html#Meetecho), or= by directly accessing the following URL:=0Ahttp://www.meetecho.com/ietf8= 1/recordings=0A=0AFor the chair(s): please feel free to put the link to t= he recording in the minutes, if you think this might be useful.=0A=0AIn c= ase of problems with the playout, just drop an e-mail to =0Aietf-support@= meetecho.com.=0A=0ACheers,=0Athe Meetecho Team