From jcole@hp.com Thu Mar 3 17:24:54 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD1B3A6806 for ; Thu, 3 Mar 2011 17:24:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqiXG2OKTNuW for ; Thu, 3 Mar 2011 17:24:53 -0800 (PST) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by core3.amsl.com (Postfix) with ESMTP id CF6543A67FC for ; Thu, 3 Mar 2011 17:24:53 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id 8DBE1C25E for ; Fri, 4 Mar 2011 01:26:01 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Mar 2011 01:25:09 +0000 Received: from GVW0673EXC.americas.hpqcorp.net ([16.230.33.202]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Fri, 4 Mar 2011 01:25:09 +0000 From: "Cole, Jim (HP Visual Collaboration R&D)" To: "clue@ietf.org" Date: Fri, 4 Mar 2011 01:25:07 +0000 Thread-Topic: CLUE use cases comment Thread-Index: AcvZ+0ns84CEhU1tRgyw2nQUvYp++w== Message-ID: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> 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] CLUE use cases comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 01:24:54 -0000 Hi, Thinking about the current set of multistream use cases, it seems that we a= lso want to cover situations in which a single endpoint is connected to inf= rastructure such as a conferencing bridge, with no other endpoints present. For example, a multistream endpoint such as a three-screen telepresence roo= m system may connect to a centralized multipoint conferencing system withou= t any other participants being connected. In addition, the conferencing sys= tem may call an endpoint. Such situations may arise by deliberate intent of= users initiating such a connection. They may also arise incidentally when,= for example, the system dials multiple endpoints to start a scheduled conf= erence, but only one answers. Typical considerations of telepresence experi= ence are not in view, because there is no other physical location, but the = multistream nature of the endpoint and infrastructure still need to be esta= blished, and capabilities of each determined. Perhaps this is a special case of a multipoint meeting, but it may include = other situations, as well. For example, if the far "site" is a recording su= bsystem. Would it make sense to cover this possibility? Regards, Jim Cole From espeberg@cisco.com Fri Mar 4 00:49:09 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8971D3A696F for ; Fri, 4 Mar 2011 00:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttsMkrLbEYY5 for ; Fri, 4 Mar 2011 00:49:08 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 680723A6974 for ; Fri, 4 Mar 2011 00:49:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=2631; q=dns/txt; s=iport; t=1299228617; x=1300438217; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=28IGhrzuDBfXRTc8uINDMM6mSBOSuXJjNhltBeN6kLo=; b=UXRfxGThTxm63rH3eMYLpVcATxWGluabYSHvzJ2G6IFPFpfv6fhR+LpD dv32xNGHMys6H4cXkNwWB+ktiQGcbtAQWxdBoscrG6OtcjKhFgiKYA2Do z1rdZ6GuSJ3Np7F0j0W6qD+OECdE1JotCw7pUt33q4aqGz2OrR02TIwVE 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEEAIY2cE2Q/khLgWdsb2JhbACmahUBARYiJaIYnAGFYQSPeA X-IronPort-AV: E=Sophos;i="4.62,263,1297036800"; d="scan'208";a="20669965" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Mar 2011 08:50:16 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p248oGOo008727; Fri, 4 Mar 2011 08:50:16 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 09:50:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 09:50:15 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E4336DF@XMB-AMS-214.cisco.com> In-Reply-To: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] CLUE use cases comment Thread-Index: AcvZ+0ns84CEhU1tRgyw2nQUvYp++wASzX7w References: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> From: "Espen Berger (espeberg)" To: "Cole, Jim (HP Visual Collaboration R&D)" , X-OriginalArrivalTime: 04 Mar 2011 08:50:16.0504 (UTC) FILETIME=[2EEE7B80:01CBDA49] Subject: Re: [clue] CLUE use cases comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 08:49:09 -0000 I think it's natural to be aware of call handling use cases to verify that our models are useful in multiple scenarios.=20 I think it's useful to group information and features into three areas=20 Multi stream and layouts * How to send and receive multiple media streams=20 * Spatial cameras and screens=20 * Audio and video codec considerations=20 * Media transport=20 Call handling=20 * How to enter a conference=20 * Do ad-hoc invite of participant=20 * ++ Conference control=20 * Roster information (e.g. RFC4575)=20 * Event notification=20 * Commands, like mute or disconnects (XCON has a draft on commands) As far as I understand CLUEs main focus is multi stream, cameras and screen handling, but must also consider call handling and conference control to make sure what we do is compatible with related standards.=20 Integration with services like recording is important to understand to make sure that we design a protocol that can be used by more services than endpoints and conference servers.=20 Cheers=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Cole, Jim (HP Visual Collaboration R&D) Sent: 4. mars 2011 02:25 To: clue@ietf.org Subject: [clue] CLUE use cases comment Hi, Thinking about the current set of multistream use cases, it seems that we also want to cover situations in which a single endpoint is connected to infrastructure such as a conferencing bridge, with no other endpoints present. For example, a multistream endpoint such as a three-screen telepresence room system may connect to a centralized multipoint conferencing system without any other participants being connected. In addition, the conferencing system may call an endpoint. Such situations may arise by deliberate intent of users initiating such a connection. They may also arise incidentally when, for example, the system dials multiple endpoints to start a scheduled conference, but only one answers. Typical considerations of telepresence experience are not in view, because there is no other physical location, but the multistream nature of the endpoint and infrastructure still need to be established, and capabilities of each determined. Perhaps this is a special case of a multipoint meeting, but it may include other situations, as well. For example, if the far "site" is a recording subsystem. Would it make sense to cover this possibility? Regards, Jim Cole _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From peter.musgrave@magorcorp.com Fri Mar 4 08:09:41 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2733A6946 for ; Fri, 4 Mar 2011 08:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YorM-JarHcNU for ; Fri, 4 Mar 2011 08:09:40 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BA0713A691B for ; Fri, 4 Mar 2011 08:09:40 -0800 (PST) Received: by iwl42 with SMTP id 42so2388937iwl.31 for ; Fri, 04 Mar 2011 08:10:49 -0800 (PST) Received: by 10.43.64.135 with SMTP id xi7mr948907icb.168.1299255048168; Fri, 04 Mar 2011 08:10:48 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id wh3sm1777508icb.12.2011.03.04.08.10.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2011 08:10:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <92DF9533227FC14F946C7321074B8C9E4336DF@XMB-AMS-214.cisco.com> Date: Fri, 4 Mar 2011 11:10:45 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <96B81138-B10D-43C4-B238-CFC336262EE9@magorcorp.com> References: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> <92DF9533227FC14F946C7321074B8C9E4336DF@XMB-AMS-214.cisco.com> To: Espen Berger (espeberg) X-Mailer: Apple Mail (2.1082) Cc: clue@ietf.org Subject: Re: [clue] CLUE use cases comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 16:09:41 -0000 Hi Espen,=20 I agree that the issues you are raising are important - but some of them = are very specifically not in scope for CLUE.=20 I think the multi-stream issues you raise are in scope.=20 Issues of call handling, rosters, event notifications, floor control are = all out of scope for CLUE we would look to other WGs if specific issues = which require protocol work arise.=20 Likewise for recording we would look to siprec.=20 Regards, Peter Musgrave On 2011-03-04, at 3:50 AM, Espen Berger (espeberg) wrote: > I think it's natural to be aware of call handling use cases to verify > that our models are useful in multiple scenarios.=20 >=20 > I think it's useful to group information and features into three areas=20= >=20 > Multi stream and layouts > * How to send and receive multiple media streams=20 > * Spatial cameras and screens=20 > * Audio and video codec considerations=20 > * Media transport=20 >=20 > Call handling=20 > * How to enter a conference=20 > * Do ad-hoc invite of participant=20 > * ++ >=20 > Conference control=20 > * Roster information (e.g. RFC4575)=20 > * Event notification=20 > * Commands, like mute or disconnects (XCON has a draft on commands) >=20 > As far as I understand CLUEs main focus is multi stream, cameras and > screen handling, but must also consider call handling and conference > control to make sure what we do is compatible with related standards.=20= >=20 > Integration with services like recording is important to understand to > make sure that we design a protocol that can be used by more services > than endpoints and conference servers.=20 >=20 > Cheers=20 >=20 > -Espen=20 >=20 >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > Cole, Jim (HP Visual Collaboration R&D) > Sent: 4. mars 2011 02:25 > To: clue@ietf.org > Subject: [clue] CLUE use cases comment >=20 > Hi, >=20 > Thinking about the current set of multistream use cases, it seems that > we also want to cover situations in which a single endpoint is = connected > to infrastructure such as a conferencing bridge, with no other = endpoints > present. >=20 > For example, a multistream endpoint such as a three-screen = telepresence > room system may connect to a centralized multipoint conferencing = system > without any other participants being connected. In addition, the > conferencing system may call an endpoint. Such situations may arise by > deliberate intent of users initiating such a connection. They may also > arise incidentally when, for example, the system dials multiple > endpoints to start a scheduled conference, but only one answers. = Typical > considerations of telepresence experience are not in view, because = there > is no other physical location, but the multistream nature of the > endpoint and infrastructure still need to be established, and > capabilities of each determined. >=20 > Perhaps this is a special case of a multipoint meeting, but it may > include other situations, as well. For example, if the far "site" is a > recording subsystem. Would it make sense to cover this possibility? >=20 > Regards, > Jim Cole > _______________________________________________ > 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 peter.musgrave@magorcorp.com Fri Mar 4 08:24:43 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3093A67A1 for ; Fri, 4 Mar 2011 08:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXYwImXEMg+3 for ; Fri, 4 Mar 2011 08:24:42 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id DDC543A67B1 for ; Fri, 4 Mar 2011 08:24:41 -0800 (PST) Received: by iyj8 with SMTP id 8so2362439iyj.31 for ; Fri, 04 Mar 2011 08:25:50 -0800 (PST) Received: by 10.42.117.3 with SMTP id r3mr765636icq.429.1299255950344; Fri, 04 Mar 2011 08:25:50 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id wt14sm1789507icb.4.2011.03.04.08.25.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2011 08:25:49 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> Date: Fri, 4 Mar 2011 11:25:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> To: "Cole, Jim (HP Visual Collaboration R&D)" X-Mailer: Apple Mail (2.1082) Cc: "clue@ietf.org" Subject: Re: [clue] CLUE use cases comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 16:24:43 -0000 Hi Jim,=20 Maybe there is a semantics issue here. I would regard a call with a user = system connected to a conference mixer as a call between two endpoints.=20= I see it as a two party call where each party uses CLUE-ish stuff to = indicate multiple streams and capabilities and then decide on what = should be send/rendered etc.=20 There is an interesting issue about mixers. Do they describe the = possible sources (all other cameras from all other participants) a user = system could elect to receive or do they just signal that there will be = e.g. 3 streams always from the same site etc. etc. At some point this = gets dangerously close to floor control which CLUE is supposed to avoid. = Do you think we need a use-case which highlights this issue? Regards, Peter Musgrave On 2011-03-03, at 8:25 PM, Cole, Jim (HP Visual Collaboration R&D) = wrote: > Hi, >=20 > Thinking about the current set of multistream use cases, it seems that = we also want to cover situations in which a single endpoint is connected = to infrastructure such as a conferencing bridge, with no other endpoints = present. >=20 > For example, a multistream endpoint such as a three-screen = telepresence room system may connect to a centralized multipoint = conferencing system without any other participants being connected. In = addition, the conferencing system may call an endpoint. Such situations = may arise by deliberate intent of users initiating such a connection. = They may also arise incidentally when, for example, the system dials = multiple endpoints to start a scheduled conference, but only one = answers. Typical considerations of telepresence experience are not in = view, because there is no other physical location, but the multistream = nature of the endpoint and infrastructure still need to be established, = and capabilities of each determined. >=20 > Perhaps this is a special case of a multipoint meeting, but it may = include other situations, as well. For example, if the far "site" is a = recording subsystem. Would it make sense to cover this possibility? >=20 > Regards, > Jim Cole > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From eckelcu@cisco.com Fri Mar 4 09:28:57 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D05C3A6946 for ; Fri, 4 Mar 2011 09:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+qGovn6RjRK for ; Fri, 4 Mar 2011 09:28:56 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 09FE33A683C for ; Fri, 4 Mar 2011 09:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3132; q=dns/txt; s=iport; t=1299259805; x=1300469405; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=2OH1bAKrMhf7ky/XrCyzX9uLuRK+2ULPHezgdteM09E=; b=DgFrBnMkZF1YZ8L1oR+jBvuDRQOS2kz7ww+JAw2CyeitPMYNGvtv5u9H ycl+DyZMYqaHbnWldO1hCUSueuyfsXpZHrb5rT0oePL8/N1T7w0q3h9mu lpmLgBNZxdh8QvQzbcXYsvO4uns1ClMohFNZL3ezS7Jq2hnw35XPKASni k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAKKwcE2rR7Ht/2dsb2JhbACYJ448dKNRm2iFYQSFHIpc X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="scan'208";a="339471575" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2011 17:29:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p24HTrQr002312; Fri, 4 Mar 2011 17:29:53 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 09:29:53 -0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 09:29:52 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] CLUE use cases comment Thread-Index: AcvaiNd6YFOGvjpDSmiCoz7mOAQuOgACKQUA References: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> From: "Charles Eckel (eckelcu)" To: "Peter Musgrave" , "Cole, Jim (HP Visual Collaboration R&D)" X-OriginalArrivalTime: 04 Mar 2011 17:29:53.0460 (UTC) FILETIME=[C5D86F40:01CBDA91] Cc: clue@ietf.org Subject: Re: [clue] CLUE use cases comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 17:28:57 -0000 I think there is not a need to model this separately. I regular endpoint may do the same thing. For example, perhaps I initially make an audio only call. Later I choose to enable my video capabilities. Then at some point I add presentation. Of course I could have offered all of these capabilities from the start, but that should not be mandatory. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave > Sent: Friday, March 04, 2011 8:26 AM > To: Cole, Jim (HP Visual Collaboration R&D) > Cc: clue@ietf.org > Subject: Re: [clue] CLUE use cases comment >=20 > Hi Jim, >=20 > Maybe there is a semantics issue here. I would regard a call with a user system connected to a > conference mixer as a call between two endpoints. >=20 > I see it as a two party call where each party uses CLUE-ish stuff to indicate multiple streams and > capabilities and then decide on what should be send/rendered etc. >=20 > There is an interesting issue about mixers. Do they describe the possible sources (all other cameras > from all other participants) a user system could elect to receive or do they just signal that there > will be e.g. 3 streams always from the same site etc. etc. At some point this gets dangerously close > to floor control which CLUE is supposed to avoid. Do you think we need a use-case which highlights > this issue? >=20 > Regards, >=20 >=20 > Peter Musgrave >=20 > On 2011-03-03, at 8:25 PM, Cole, Jim (HP Visual Collaboration R&D) wrote: >=20 > > Hi, > > > > Thinking about the current set of multistream use cases, it seems that we also want to cover > situations in which a single endpoint is connected to infrastructure such as a conferencing bridge, > with no other endpoints present. > > > > For example, a multistream endpoint such as a three-screen telepresence room system may connect to a > centralized multipoint conferencing system without any other participants being connected. In > addition, the conferencing system may call an endpoint. Such situations may arise by deliberate intent > of users initiating such a connection. They may also arise incidentally when, for example, the system > dials multiple endpoints to start a scheduled conference, but only one answers. Typical considerations > of telepresence experience are not in view, because there is no other physical location, but the > multistream nature of the endpoint and infrastructure still need to be established, and capabilities > of each determined. > > > > Perhaps this is a special case of a multipoint meeting, but it may include other situations, as > well. For example, if the far "site" is a recording subsystem. Would it make sense to cover this > possibility? > > > > Regards, > > Jim Cole > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From eckelcu@cisco.com Fri Mar 4 09:29:03 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 256DD3A69C7 for ; Fri, 4 Mar 2011 09:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl+6a64tu-8b for ; Fri, 4 Mar 2011 09:29:02 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D81223A683C for ; Fri, 4 Mar 2011 09:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=3994; q=dns/txt; s=iport; t=1299259811; x=1300469411; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SOW9++fBMcM8VG3w7iXJYnzBMhfDdTctiW+ht22wuTg=; b=J7QTzUKa+zXE/TWwmPllaaYnG8M0VOMh8XLO1rK8uK9pX5g8nSWfU+kh ji0q0Xi/9wWoPPVvowKqtttzmcNvibRdZaIr407S0fqprWHeUqvhFn9do Ql2Eq5tkp+fPKszGkNALanYDidRA5ZUGd0CtphEnezCo3NIH8Dv0pw97Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkBAN6wcE2rRN+J/2dsb2JhbACYJ448dKNTm2iFYQSFHIpc X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="scan'208";a="412187989" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2011 17:30:02 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p24HU281021301; Fri, 4 Mar 2011 17:30:03 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); Fri, 4 Mar 2011 09:30:02 -0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 09:30:01 -0800 Message-ID: In-Reply-To: <96B81138-B10D-43C4-B238-CFC336262EE9@magorcorp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] CLUE use cases comment Thread-Index: Acvahr/Po8kRdyzKRGe7Gx88IiSGrQACwg3w References: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net><92DF9533227FC14F946C7321074B8C9E4336DF@XMB-AMS-214.cisco.com> <96B81138-B10D-43C4-B238-CFC336262EE9@magorcorp.com> From: "Charles Eckel (eckelcu)" To: "Peter Musgrave" , "Espen Berger (espeberg)" X-OriginalArrivalTime: 04 Mar 2011 17:30:02.0299 (UTC) FILETIME=[CB1D28B0:01CBDA91] Cc: clue@ietf.org Subject: Re: [clue] CLUE use cases comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 17:29:03 -0000 +1 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave > Sent: Friday, March 04, 2011 8:11 AM > To: Espen Berger (espeberg) > Cc: clue@ietf.org > Subject: Re: [clue] CLUE use cases comment >=20 > Hi Espen, >=20 > I agree that the issues you are raising are important - but some of them are very specifically not in > scope for CLUE. >=20 > I think the multi-stream issues you raise are in scope. >=20 > Issues of call handling, rosters, event notifications, floor control are all out of scope for CLUE we > would look to other WGs if specific issues which require protocol work arise. >=20 > Likewise for recording we would look to siprec. >=20 > Regards, >=20 > Peter Musgrave >=20 > On 2011-03-04, at 3:50 AM, Espen Berger (espeberg) wrote: >=20 > > I think it's natural to be aware of call handling use cases to verify > > that our models are useful in multiple scenarios. > > > > I think it's useful to group information and features into three areas > > > > Multi stream and layouts > > * How to send and receive multiple media streams > > * Spatial cameras and screens > > * Audio and video codec considerations > > * Media transport > > > > Call handling > > * How to enter a conference > > * Do ad-hoc invite of participant > > * ++ > > > > Conference control > > * Roster information (e.g. RFC4575) > > * Event notification > > * Commands, like mute or disconnects (XCON has a draft on commands) > > > > As far as I understand CLUEs main focus is multi stream, cameras and > > screen handling, but must also consider call handling and conference > > control to make sure what we do is compatible with related standards. > > > > Integration with services like recording is important to understand to > > make sure that we design a protocol that can be used by more services > > than endpoints and conference servers. > > > > Cheers > > > > -Espen > > > > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Cole, Jim (HP Visual Collaboration R&D) > > Sent: 4. mars 2011 02:25 > > To: clue@ietf.org > > Subject: [clue] CLUE use cases comment > > > > Hi, > > > > Thinking about the current set of multistream use cases, it seems that > > we also want to cover situations in which a single endpoint is connected > > to infrastructure such as a conferencing bridge, with no other endpoints > > present. > > > > For example, a multistream endpoint such as a three-screen telepresence > > room system may connect to a centralized multipoint conferencing system > > without any other participants being connected. In addition, the > > conferencing system may call an endpoint. Such situations may arise by > > deliberate intent of users initiating such a connection. They may also > > arise incidentally when, for example, the system dials multiple > > endpoints to start a scheduled conference, but only one answers. Typical > > considerations of telepresence experience are not in view, because there > > is no other physical location, but the multistream nature of the > > endpoint and infrastructure still need to be established, and > > capabilities of each determined. > > > > Perhaps this is a special case of a multipoint meeting, but it may > > include other situations, as well. For example, if the far "site" is a > > recording subsystem. Would it make sense to cover this possibility? > > > > Regards, > > Jim Cole > > _______________________________________________ > > 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 jcole@hp.com Fri Mar 4 10:35:11 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A1A3A69FF for ; Fri, 4 Mar 2011 10:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74nRyhg0vrYd for ; Fri, 4 Mar 2011 10:35:10 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id DF2DB3A6A0E for ; Fri, 4 Mar 2011 10:35:09 -0800 (PST) Received: from G5W0603.americas.hpqcorp.net (g5w0603.americas.hpqcorp.net [16.228.9.186]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id B314B38853; Fri, 4 Mar 2011 18:36:18 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G5W0603.americas.hpqcorp.net (16.228.9.186) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Mar 2011 18:35:30 +0000 Received: from GVW0673EXC.americas.hpqcorp.net ([16.230.33.202]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Fri, 4 Mar 2011 18:35:30 +0000 From: "Cole, Jim (HP Visual Collaboration R&D)" To: "Charles Eckel (eckelcu)" , Peter Musgrave Date: Fri, 4 Mar 2011 18:35:27 +0000 Thread-Topic: [clue] CLUE use cases comment Thread-Index: AcvaiNd6YFOGvjpDSmiCoz7mOAQuOgACKQUAAAF1uZA= Message-ID: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5DB9C@GVW0673EXC.americas.hpqcorp.net> References: <057BEE3C39FE5D48ADBD41D1DE16022C197EA5D7DE@GVW0673EXC.americas.hpqcorp.net> 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] CLUE use cases comment X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 04 Mar 2011 18:35:11 -0000 If I understand correctly, the question of what capabilities are presented = is different than the question of mandating a mixer's use of the available = capabilities. I don't think we need a specific use case for the latter, and= tend to agree that doing so may push the limits of CLUE's work. On the other hand, we do need to consider the kinds of dynamic behavior tha= t can occur as endpoints offer new capabilities, rich endpoints come and go= , etc. So the point of the additional use case would be simply to make sure= we cover a (perhaps degenerate) case of multistream endpoints in which onl= y one is a physical site.=20 I agree that a user connected to a conference mixer is a call between two e= ndpoints. But isn't that true of any multipoint call? So we want to make su= re to cover enough cases so that the CLUE stuff is complete. Jim -----Original Message----- From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]=20 Sent: Friday, March 04, 2011 9:30 AM To: Peter Musgrave; Cole, Jim (HP Visual Collaboration R&D) Cc: clue@ietf.org Subject: RE: [clue] CLUE use cases comment I think there is not a need to model this separately. I regular endpoint ma= y do the same thing. For example, perhaps I initially make an audio only ca= ll. Later I choose to enable my video capabilities. Then at some point I ad= d presentation. Of course I could have offered all of these capabilities fr= om the start, but that should not be mandatory. Cheers, Charles > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Peter Musgrave > Sent: Friday, March 04, 2011 8:26 AM > To: Cole, Jim (HP Visual Collaboration R&D) > Cc: clue@ietf.org > Subject: Re: [clue] CLUE use cases comment >=20 > Hi Jim, >=20 > Maybe there is a semantics issue here. I would regard a call with a user system connected to a > conference mixer as a call between two endpoints. >=20 > I see it as a two party call where each party uses CLUE-ish stuff to indicate multiple streams and > capabilities and then decide on what should be send/rendered etc. >=20 > There is an interesting issue about mixers. Do they describe the possible sources (all other cameras > from all other participants) a user system could elect to receive or do they just signal that there > will be e.g. 3 streams always from the same site etc. etc. At some point this gets dangerously close > to floor control which CLUE is supposed to avoid. Do you think we need a use-case which highlights > this issue? >=20 > Regards, >=20 >=20 > Peter Musgrave >=20 > On 2011-03-03, at 8:25 PM, Cole, Jim (HP Visual Collaboration R&D) wrote: >=20 > > Hi, > > > > Thinking about the current set of multistream use cases, it seems that we also want to cover > situations in which a single endpoint is connected to infrastructure such as a conferencing bridge, > with no other endpoints present. > > > > For example, a multistream endpoint such as a three-screen telepresence room system may connect to a > centralized multipoint conferencing system without any other participants being connected. In > addition, the conferencing system may call an endpoint. Such situations may arise by deliberate intent > of users initiating such a connection. They may also arise incidentally when, for example, the system > dials multiple endpoints to start a scheduled conference, but only one answers. Typical considerations > of telepresence experience are not in view, because there is no other physical location, but the > multistream nature of the endpoint and infrastructure still need to be established, and capabilities > of each determined. > > > > Perhaps this is a special case of a multipoint meeting, but it may include other situations, as > well. For example, if the far "site" is a recording subsystem. Would it make sense to cover this > possibility? > > > > Regards, > > Jim Cole > > _______________________________________________ > > 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 allyn@cisco.com Fri Mar 4 21:46:36 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD073A689E for ; Fri, 4 Mar 2011 21:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7lkbSRu15An for ; Fri, 4 Mar 2011 21:46:34 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1EDD83A6925 for ; Fri, 4 Mar 2011 21:46:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=1454; q=dns/txt; s=iport; t=1299304064; x=1300513664; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=jNfL5Z8i4zjTTwFjVC2rvjBvm33sClZzKqk+2oMqhqo=; b=ZNIe4MWbo54wTEZzHVxe75i9yVO7R4Z1j0t52r3r2JEyat/KagRDyrf0 M+gdH691314XGFk4FcP5Y42dueJy7Kr+gYBXDNDEske0R5jgXl3epejr2 yUj8ZmDd+OlEHDDNk1z5Dz+Jct4g6V7OZSQsh8YFOBCU3pUCvOZdTBIkt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAOdccU2rR7Ht/2dsb2JhbACEKZQBP40cYHSiJosMkCaBJ4NEdgSFHIpc X-IronPort-AV: E=Sophos;i="4.62,268,1297036800"; d="scan'208";a="339751355" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 05 Mar 2011 05:47:43 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p255liLC026638 for ; Sat, 5 Mar 2011 05:47:44 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); Fri, 4 Mar 2011 21:47:43 -0800 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: Fri, 4 Mar 2011 21:47:42 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-romanow-clue-telepresence-requirements-00 Thread-Index: Acva9KFK4CNwOGOkSXyP3pkHEpVuyQAAiujQ From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 05 Mar 2011 05:47:43.0940 (UTC) FILETIME=[D91B9840:01CBDAF8] Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 05 Mar 2011 05:46:36 -0000 SGkgRm9sa3MsDQoNCkkganVzdCBzdWJtaXR0ZWQgdGhpcyBmaXJzdCBkcmFmdCBvZiBhIHJlcXVp cmVtZW50cyBkb2N1bWVudC4NCg0KTG9va2luZyBmb3J3YXJkIHRvIHlvdXIgdGhvdWdodHMtDQoN CkFsbHluDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBTdWJt aXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5 LCBNYXJjaCAwNCwgMjAxMSA5OjE2IFBNDQpUbzogQWxseW4gUm9tYW5vdyAoYWxseW4pDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJvbWFub3ctY2x1ZS10ZWxl cHJlc2VuY2UtcmVxdWlyZW1lbnRzLTAwIA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1yb21hbm93LWNsdWUtdGVsZXByZXNlbmNlLXJlcXVpcmVtZW50cy0wMC50eHQgaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBBbGx5biBSb21hbm93IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1yb21hbm93LWNsdWUtdGVsZXBy ZXNlbmNlLXJlcXVpcmVtZW50cw0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkgUmVxdWlyZW1lbnRz IGZvciBUZWxlcHJlc2VuY2UgTXVsdGktU3RyZWFtcw0KQ3JlYXRpb25fZGF0ZToJIDIwMTEtMDMt MDUNCldHIElEOgkJIEluZGVwZW5kZW50IFN1Ym1pc3Npb24NCk51bWJlcl9vZl9wYWdlczogMTEN Cg0KQWJzdHJhY3Q6DQpUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgcHJvYmxlbXMsIGFzc3Vt cHRpb25zLCBhbmQgcmVxdWlyZW1lbnRzDQpmb3IgaGFuZGxpbmcgbXVsdGlwbGUgbWVkaWEgc3Ry ZWFtcyB0byBlbmFibGUgVGVsZXByZXNlbmNlDQppbnRlcm9wZXJhYmlsaXR5LiAgRGVmaW5pdGlv bnMgYXJlIGFsc28gY292ZXJlZCBoZXJlIGFzIHdlbGwuDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K From magnus.westerlund@ericsson.com Mon Mar 7 07:38:46 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABCDB3A67E2 for ; Mon, 7 Mar 2011 07:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.428 X-Spam-Level: X-Spam-Status: No, score=-106.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dk2FmgSoW4O8 for ; Mon, 7 Mar 2011 07:38:45 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 83E323A67D3 for ; Mon, 7 Mar 2011 07:38:45 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-66-4d74fc4eb748 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D8.7F.21265.E4CF47D4; Mon, 7 Mar 2011 16:39:58 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 7 Mar 2011 16:39:57 +0100 Message-ID: <4D74FC4D.6080102@ericsson.com> Date: Mon, 7 Mar 2011 16:39:57 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Lauwers, Chris" References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com> <4D6BD1F0.5080106@ericsson.com> <286AB014A111DC4C8A3720297DD5F7900131C9F2@rsmail01.avistar.com> In-Reply-To: <286AB014A111DC4C8A3720297DD5F7900131C9F2@rsmail01.avistar.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 15:38:46 -0000 Lauwers, Chris skrev 2011-02-28 23:18: > Magnus, > > The "RTP Payload Format for SVC" draft > (http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-27) proposes > multiplexing different layers of the same SVC stream within the same > RTP session (and potentially different SVC streams associated with a > multi-party conference as well). Based on your analysis below, do you > consider that an appropriate use of RTP multiplexing? Yes, it is. The different layers part of an SVC stream do provide different quality levels for an single source. In cases when you don't need QoS and rely on MANEs for adaptation, like in cases with a central bridge then this is appropriate. If you have other requirements then you may need to use multiple RTP sessions, like in the case of using multicast and splitting the layers over different addresses to allow each receiver to join what it is capable of receiving. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From thomas.schierl@hhi.fraunhofer.de Mon Mar 7 07:52:17 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 320393A67E1 for ; Mon, 7 Mar 2011 07:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvyguurmUsvt for ; Mon, 7 Mar 2011 07:52:14 -0800 (PST) Received: from mailgw.hhi.fraunhofer.de (mail.HHI.FRAUNHOFER.DE [193.174.67.45]) by core3.amsl.com (Postfix) with ESMTP id 7DE0F3A67D3 for ; Mon, 7 Mar 2011 07:52:14 -0800 (PST) X-IMSS-DKIM-Authentication-Result: mailgw.hhi.fraunhofer.de; sigcount=0 Received: from [130.149.228.79] (ic638001.ic.tu-berlin.de [130.149.228.79]) by mailgw.hhi.fraunhofer.de (Postfix) with ESMTP id C97D9186809E; Mon, 7 Mar 2011 16:54:21 +0100 (CET) Message-ID: <4D74FF76.9020702@hhi.fraunhofer.de> Date: Mon, 07 Mar 2011 16:53:26 +0100 From: Thomas Schierl Organization: Fraunhofer-Institut fuer Nachrichtentechnik Heinrich-Hertz-Institut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Magnus Westerlund References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com> <4D6BD1F0.5080106@ericsson.com> <286AB014A111DC4C8A3720297DD5F7900131C9F2@rsmail01.avistar.com> <4D74FC4D.6080102@ericsson.com> In-Reply-To: <4D74FC4D.6080102@ericsson.com> Content-Type: multipart/alternative; boundary="------------020507030006030106050600" X-alterMIME: Yes Cc: "Lauwers, Chris" , CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 15:52:17 -0000 This is a multi-part message in MIME format. --------------020507030006030106050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear Magnus, During the standardization process of the RTP payload format for SVC, we also found out that the SSRC multiplexing is in some cases an appropriate method to distinguish between layers within a single RTP session. This for sure has advantages over payload specific methods, since generic RTP mechanisms can be used. The fact has further been discussed in RFC 6051. Best regards, Thomas On 07.03.2011 16:39, Magnus Westerlund wrote: > Lauwers, Chris skrev 2011-02-28 23:18: >> Magnus, >> >> The "RTP Payload Format for SVC" draft >> (http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-27) proposes >> multiplexing different layers of the same SVC stream within the same >> RTP session (and potentially different SVC streams associated with a >> multi-party conference as well). Based on your analysis below, do you >> consider that an appropriate use of RTP multiplexing? > Yes, it is. The different layers part of an SVC stream do provide > different quality levels for an single source. In cases when you don't > need QoS and rely on MANEs for adaptation, like in cases with a central > bridge then this is appropriate. If you have other requirements then you > may need to use multiple RTP sessions, like in the case of using > multicast and splitting the layers over different addresses to allow > each receiver to join what it is capable of receiving. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > -- Visit us at CeBIT 2011 / March 1-5 / Hanover, Germany / Hall 9, Booth B36 + Hall 15 Booth A24 http://www.hhi.fraunhofer.de/cebit OFC 2011 / March 8-10 / Los Angeles, Convention Center, USA / booth 2037 http://www.ofcnfoec.org Web 2.0 / March 28-31 / San Francisco, Moscone West, USA / booth 824 http://www.web2expo.com --------------020507030006030106050600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Magnus,

During the standardization process of the RTP payload format for SVC, we also found out that the SSRC multiplexing is in some cases an appropriate method to distinguish between layers within a single RTP session. This for sure has advantages over payload specific methods, since generic RTP mechanisms can be used. The fact has further been discussed in RFC 6051.

Best regards,
Thomas

On 07.03.2011 16:39, Magnus Westerlund wrote: 
Lauwers, Chris skrev 2011-02-28 23:18:

Magnus,

The "RTP Payload Format for SVC" draft
(http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-27) proposes
multiplexing different layers of the same SVC stream within the same
RTP session (and potentially different SVC streams associated with a
multi-party conference as well). Based on your analysis below, do you
consider that an appropriate use of RTP multiplexing?

Yes, it is. The different layers part of an SVC stream do provide
different quality levels for an single source. In cases when you don't
need QoS and rely on MANEs for adaptation, like in cases with a central
bridge then this is appropriate. If you have other requirements then you
may need to use multiple RTP sessions, like in the case of using
multicast and splitting the layers over different addresses to allow
each receiver to join what it is capable of receiving.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue




-- 
Visit us at

CeBIT 2011 / March 1-5 / Hanover, Germany / hall 9, booth B36 + hall 15 booth A24
http://www.hhi.fraunhofer.de/cebit

OFC 2011 / March 8-10 / Los Angeles, Convention Center, USA / booth 2037
http://www.ofcnfoec.org

Web 2.0 / March 28-31 / San Francisco, Moscone West, USA / booth 824
http://www.web2expo.com

--------------020507030006030106050600-- From peter.musgrave@magorcorp.com Mon Mar 7 11:50:53 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579973A6804 for ; Mon, 7 Mar 2011 11:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rH1qt5dO7QXr for ; Mon, 7 Mar 2011 11:50:52 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 68A003A67F9 for ; Mon, 7 Mar 2011 11:50:52 -0800 (PST) Received: by iwl42 with SMTP id 42so5260669iwl.31 for ; Mon, 07 Mar 2011 11:52:06 -0800 (PST) Received: by 10.231.32.136 with SMTP id c8mr962137ibd.144.1299527526065; Mon, 07 Mar 2011 11:52:06 -0800 (PST) Received: from petermac.magor.local ([72.1.217.106]) by mx.google.com with ESMTPS id gy41sm3007989ibb.23.2011.03.07.11.52.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2011 11:52:05 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Peter Musgrave In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> Date: Mon, 7 Mar 2011 14:52:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <80E9B992-5363-44CF-9741-63ACB5FC2BB5@magorcorp.com> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> To: Allyn Romanow (allyn) X-Mailer: Apple Mail (2.1082) Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 07 Mar 2011 19:50:53 -0000 Hi Allyn,=20 Overall this is big step forward. Thanks.=20 A couple of quick comments (I still need to re-read carefully) RQMT-6: Support for H.264 baseline This feels a bit like a media profile (and there is no corresponding one = for audio). I suspect this is out of scope - since CLUE is about = semantics of streams and not requirements as to what CODEC be used... RQMT-12 talks about SDP streams. Should this say RTP streams? Regards,=20 Peter Musgrave On 2011-03-05, at 12:47 AM, Allyn Romanow (allyn) wrote: > Hi Folks, >=20 > I just submitted this first draft of a requirements document. >=20 > Looking forward to your thoughts- >=20 > Allyn >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 > Sent: Friday, March 04, 2011 9:16 PM > To: Allyn Romanow (allyn) > Subject: New Version Notification for = draft-romanow-clue-telepresence-requirements-00=20 >=20 >=20 > A new version of I-D, = draft-romanow-clue-telepresence-requirements-00.txt has been = successfully submitted by Allyn Romanow and posted to the IETF = repository. >=20 > Filename: draft-romanow-clue-telepresence-requirements > Revision: 00 > Title: Requirements for Telepresence Multi-Streams > Creation_date: 2011-03-05 > WG ID: Independent Submission > Number_of_pages: 11 >=20 > Abstract: > This document discusses the problems, assumptions, and requirements > for handling multiple media streams to enable Telepresence > interoperability. Definitions are also covered here as well. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From magnus.westerlund@ericsson.com Tue Mar 8 00:50:25 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A953A6866 for ; Tue, 8 Mar 2011 00:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.445 X-Spam-Level: X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IryhrzW9xUGH for ; Tue, 8 Mar 2011 00:50:21 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B2D563A67B8 for ; Tue, 8 Mar 2011 00:50:20 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-3e-4d75ee162e08 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.9B.21265.61EE57D4; Tue, 8 Mar 2011 09:51:34 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.2.234.1; Tue, 8 Mar 2011 09:51:34 +0100 Message-ID: <4D75EE16.4010801@ericsson.com> Date: Tue, 8 Mar 2011 09:51:34 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Thomas Schierl References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com> <4D6BD1F0.5080106@ericsson.com> <286AB014A111DC4C8A3720297DD5F7900131C9F2@rsmail01.avistar.com> <4D74FC4D.6080102@ericsson.com> <4D74FF76.9020702@hhi.fraunhofer.de> In-Reply-To: <4D74FF76.9020702@hhi.fraunhofer.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "Lauwers, Chris" , CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 08:50:26 -0000 Thomas Schierl skrev 2011-03-07 16:53: > Dear Magnus, > > During the standardization process of the RTP payload format for SVC, we > also found out that the SSRC multiplexing is in some cases an > appropriate method to distinguish between layers within a single RTP > session. This for sure has advantages over payload specific methods, > since generic RTP mechanisms can be used. The fact has further been > discussed in RFC 6051. > Sure, it does have some drawbacks but clearly some advantages also. In general when it comes on how to demultiplex things, one needs to carefully consider what the goals are, in which application context one will use it and what drawbacks or limitations one can accept. The fact that one want to reach many application contexts with SVC RTP payload format is also the reason one ends up with several alternative solutions. Thus, the application needs to choose the solution that fits their requirements. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From espeberg@cisco.com Tue Mar 8 01:39:22 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDEE3A67DA for ; Tue, 8 Mar 2011 01:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqQASbICTznF for ; Tue, 8 Mar 2011 01:39:20 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 086123A67AC for ; Tue, 8 Mar 2011 01:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=2190; q=dns/txt; s=iport; t=1299577235; x=1300786835; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ueoUyqNmUcCD1CKKpL++CduTkylkQQ6ndv4mmXgv1DA=; b=fsyHfe56r+ECMgzmaqvf4gySt+JA49zC1eVscdlXTa2T+hxTNERVJo7V m8LogMCrDdiZ2T1L6HeV6A5zXLQkbEAB8RIsC3o3DTt6HQZt8tVGduWsR epxe3te5LUhTN6y11QElVmN/vpvauzuIZnTErgsYR5qE54aQn4l+65/St U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEAIWIdU2Q/khMgWdsb2JhbACmPRUBARYiJaICnEMChWAEj34 X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208";a="20905892" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2011 09:40:33 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p289eXGb002000; Tue, 8 Mar 2011 09:40:33 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 10:40:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 10:40:32 +0100 Message-ID: <92DF9533227FC14F946C7321074B8C9E4A9600@XMB-AMS-214.cisco.com> In-Reply-To: <4D74FC4D.6080102@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] RTP Muxing Guidance Thread-Index: Acvc3jBdZnj9kKBpQyWQpsRhaurxqgAlilwg References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com><4D6BD1F0.5080106@ericsson.com><286AB014A111DC4C8A3720297DD5F7900131C9F2@rsmail01.avistar.com> <4D74FC4D.6080102@ericsson.com> From: "Espen Berger (espeberg)" To: "Magnus Westerlund" , "Lauwers, Chris" X-OriginalArrivalTime: 08 Mar 2011 09:40:34.0291 (UTC) FILETIME=[DF533C30:01CBDD74] Cc: CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 09:39:22 -0000 We have two important use cases for multiplexing video, sending spatial = video streams (e.g. left, center, right camera) and receive video for = multiple screens.=20 I think both fits into the RTP model with multiple RTP streams on the = same RTP session. Currently a separate RTP session for audio and video = is used, which gives the possibility to assign individual QoS to audio = and video.=20 Regards=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Magnus Westerlund Sent: 7. mars 2011 16:40 To: Lauwers, Chris Cc: CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance Lauwers, Chris skrev 2011-02-28 23:18: > Magnus, >=20 > The "RTP Payload Format for SVC" draft > (http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-27) proposes > multiplexing different layers of the same SVC stream within the same > RTP session (and potentially different SVC streams associated with a > multi-party conference as well). Based on your analysis below, do you > consider that an appropriate use of RTP multiplexing? Yes, it is. The different layers part of an SVC stream do provide different quality levels for an single source. In cases when you don't need QoS and rely on MANEs for adaptation, like in cases with a central bridge then this is appropriate. If you have other requirements then you may need to use multiple RTP sessions, like in the case of using multicast and splitting the layers over different addresses to allow each receiver to join what it is capable of receiving. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Tue Mar 8 04:34:10 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB7B3A6821 for ; Tue, 8 Mar 2011 04:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.585 X-Spam-Level: X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRNHKjLl+UEY for ; Tue, 8 Mar 2011 04:34:10 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A9CBC3A63D2 for ; Tue, 8 Mar 2011 04:34:09 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-d0-4d76228b8605 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 26.E9.21265.B82267D4; Tue, 8 Mar 2011 13:35:23 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 8 Mar 2011 13:35:20 +0100 From: Christer Holmberg To: "Allyn Romanow (allyn)" , "clue@ietf.org" Date: Tue, 8 Mar 2011 13:35:19 +0100 Thread-Topic: Telepresence requirements: Endpoint definition [was: New Version Notification for draft-romanow-clue-telepresence-requirements-00] Thread-Index: Acva9KFK4CNwOGOkSXyP3pkHEpVuyQAAiujQAKV80cA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948FA9C1E@ESESSCMS0356.eemea.ericsson.se> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] Telepresence requirements: Endpoint definition [was: New Version Notification for draft-romanow-clue-telepresence-requirements-00] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 08 Mar 2011 12:34:11 -0000 Hi, A comment on the "Endpoint" definition. It talks about "end system", and also refers to the "Room" definition, whic= h at least to me relates to telepresence rooms etc. But, I assume it also covers normal phones, hand held devices etc. I guess = it would be good to mention that. Regards, Christer From magnus.westerlund@ericsson.com Wed Mar 9 07:28:51 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F028F3A6866 for ; Wed, 9 Mar 2011 07:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.465 X-Spam-Level: X-Spam-Status: No, score=-106.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtY9+Fe-qnZL for ; Wed, 9 Mar 2011 07:28:49 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 428293A6821 for ; Wed, 9 Mar 2011 07:28:48 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-b5-4d779cfce32e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.DB.09202.CFC977D4; Wed, 9 Mar 2011 16:30:05 +0100 (CET) Received: from [147.214.183.8] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Wed, 9 Mar 2011 16:27:20 +0100 Message-ID: <4D779C58.8060002@ericsson.com> Date: Wed, 9 Mar 2011 16:27:20 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Espen Berger (espeberg)" References: <4d62d966.5097cc0a.5f21.ffff9a41@mx.google.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC039D71DF@xmb-sjc-221.amer.cisco.com><4D6BD1F0.5080106@ericsson.com><286AB014A111DC4C8A3720297DD5F7900131C9F2@rsmail01.avistar.com> <4D74FC4D.6080102@ericsson.com> <92DF9533227FC14F946C7321074B8C9E4A9600@XMB-AMS-214.cisco.com> In-Reply-To: <92DF9533227FC14F946C7321074B8C9E4A9600@XMB-AMS-214.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "Lauwers, Chris" , CLUE CLUE Subject: Re: [clue] RTP Muxing Guidance X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 15:28:51 -0000 Hi Espen, Espen Berger (espeberg) skrev 2011-03-08 10:40: > We have two important use cases for multiplexing video, sending > spatial video streams (e.g. left, center, right camera) and receive > video for multiple screens. Yes, there is different reasons for how one transmit information within RTP sessions. Thus there is need to review what the goals and requirements are here. > > I think both fits into the RTP model with multiple RTP streams on the > same RTP session. Currently a separate RTP session for audio and > video is used, which gives the possibility to assign individual QoS > to audio and video. > It is not unlikely that you are correct, however in general I think there is need for reviewing goals and requirements. It is also likely that for example how RTP is to handle multi-view media sources is not a CLUE issue at all, it belongs in the right AVT group. AVTCore, AVTExt and Payload are all possible WGs depending on which questions that needs to be tackled. I think it is good that people starts thinking about these problems, but can we please start looking it at from a use case and requirement perspective and try to write down that. What are the goals, what known limitations exist etc. Lets start in this area and then later we will come to the discussion on how to resolve things. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jcole@hp.com Wed Mar 9 13:19:17 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74FD83A6943 for ; Wed, 9 Mar 2011 13:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKsK2j962yrc for ; Wed, 9 Mar 2011 13:19:16 -0800 (PST) Received: from g4t0014.houston.hp.com (g4t0014.houston.hp.com [15.201.24.17]) by core3.amsl.com (Postfix) with ESMTP id 5BC433A6AA2 for ; Wed, 9 Mar 2011 13:19:16 -0800 (PST) Received: from G1W0401.americas.hpqcorp.net (g1w0401.americas.hpqcorp.net [16.236.31.6]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0014.houston.hp.com (Postfix) with ESMTPS id 7E96B24F57; Wed, 9 Mar 2011 21:20:31 +0000 (UTC) Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G1W0401.americas.hpqcorp.net (16.236.31.6) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Mar 2011 21:19:21 +0000 Received: from GVW0673EXC.americas.hpqcorp.net ([16.230.33.202]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Wed, 9 Mar 2011 21:19:17 +0000 From: "Cole, Jim (HP Visual Collaboration R&D)" To: "Allyn Romanow (allyn)" Date: Wed, 9 Mar 2011 21:19:15 +0000 Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00 Thread-Index: Acva9KFK4CNwOGOkSXyP3pkHEpVuyQAAiujQAOnR+WA= Message-ID: <057BEE3C39FE5D48ADBD41D1DE16022C197EBB4642@GVW0673EXC.americas.hpqcorp.net> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 09 Mar 2011 21:19:17 -0000 Hi, Regarding some of the definitions, I wonder to what extent it would be wort= h minimizing new terms, and instead extending existing nomenclatures. Some = suggestions along these lines are below, along with a couple other comments= on definitions and the requirements themselves. Regards, Jim Cole 1. "Endpoint" and "Room". What is the difference between an endpoint and a = SIP user agent? Could we use "multistream user agent" instead? That would g= ive a generic term applicable to phones, desktop applications, etc. Also, i= f terms are used interchangeably, would it be better to try and standardize= on one for the purposes of the documents? 2. "Layout" and "Source placement". Why have both, since one is aka the oth= er? Suggest removing Source placement, and just using Layout to refer to th= e general task of arranging rendered streams at a receiving endpoint, wheth= er this means mapping specific streams to specific displays, or creating a = composited (mixed) presentation at the receiving endpoint. 3. "Region". Can this be clarified as to how it differs from field of view?= Would an alternative be to define a spatial metric with which to describe = capture field of view? Perhaps an example would be helpful. 4. "Source selection". Seems like this is a special case of the general mix= ing function; when streams are not combined. Instead, how about if we use t= he well-known term "mixer", and expand it. SIP expanded the definition from= RTP to include non-RTP data. CLUE could likewise expand the definition to = include multistream sessions, which could then explicitly include the simpl= e case of source selection. 5. "Video composite". Following some of the comments above, how about this = simply becoming the output of a multistream mixer? 6. REQMT-1. Is there an implied requirement to determine a (synthetic) spat= ial relationship between multiple endpoints? 7. REQMT-4. Just to be clear, the sender can either be the originating endp= oint, or a middlebox, right? 8. REQMT-21. Since this is under "Audio", is it really referring to lipsync= ? Or is it a higher-level latency requirement for both audio and video. Pro= bably need both. -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of All= yn Romanow (allyn) Sent: Friday, March 04, 2011 9:48 PM To: clue@ietf.org Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepre= sence-requirements-00 Hi Folks, I just submitted this first draft of a requirements document. Looking forward to your thoughts- Allyn -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Friday, March 04, 2011 9:16 PM To: Allyn Romanow (allyn) Subject: New Version Notification for draft-romanow-clue-telepresence-requi= rements-00=20 A new version of I-D, draft-romanow-clue-telepresence-requirements-00.txt h= as been successfully submitted by Allyn Romanow and posted to the IETF repo= sitory. Filename: draft-romanow-clue-telepresence-requirements Revision: 00 Title: Requirements for Telepresence Multi-Streams Creation_date: 2011-03-05 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document discusses the problems, assumptions, and requirements for handling multiple media streams to enable Telepresence interoperability. Definitions are also covered here as well. = =20 The IETF Secretariat. _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Wed Mar 9 16:49:23 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8080A3A698A for ; Wed, 9 Mar 2011 16:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC1eZtCeSSp5 for ; Wed, 9 Mar 2011 16:49:22 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3C1063A6B16 for ; Wed, 9 Mar 2011 16:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4304; q=dns/txt; s=iport; t=1299718239; x=1300927839; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7ClaknNudjvWSZWRhE4b2GX0anYuumSWzlrlpnx+Q4Q=; b=QXwlA46Ar1cupBzBkT1WO82BwjQD76EWjtvlQ21iegVNsATUNYBrF71Z mPpPatDyQqAXYocWcwXCHR6pENyghznF4Ff59QZ/vYtU6tUw/0eW/en8S p4KYFKFaA4xDGSMMA9OXmch0iH5yaUTUulug8q7hxBthzXJHPbbavhKYh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAH6vd02rRN+J/2dsb2JhbACYRY4tdKZwnECFZQSFIopm X-IronPort-AV: E=Sophos;i="4.62,293,1297036800"; d="scan'208";a="343365668" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2011 00:50:39 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p2A0odvd001579; Thu, 10 Mar 2011 00:50:39 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, 9 Mar 2011 16:50:39 -0800 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, 9 Mar 2011 16:50:37 -0800 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03C7881E@xmb-sjc-221.amer.cisco.com> In-Reply-To: <057BEE3C39FE5D48ADBD41D1DE16022C197EBB4642@GVW0673EXC.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] FW: New Version Notification fordraft-romanow-clue-telepresence-requirements-00 Thread-Index: Acva9KFK4CNwOGOkSXyP3pkHEpVuyQAAiujQAOnR+WAAB7u88A== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> <057BEE3C39FE5D48ADBD41D1DE16022C197EBB4642@GVW0673EXC.americas.hpqcorp.net> From: "Allyn Romanow (allyn)" To: "Cole, Jim (HP Visual Collaboration R&D)" , "Christer Holmberg" , "Peter Musgrave" X-OriginalArrivalTime: 10 Mar 2011 00:50:39.0031 (UTC) FILETIME=[2CB31470:01CBDEBD] Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification fordraft-romanow-clue-telepresence-requirements-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 10 Mar 2011 00:49:23 -0000 Hi Jim, Christer and Peter- I'll be able to respond to your emails about requirements in the next few days.. just haven't had a chance yet. Thanks, Allyn > -----Original Message----- > From: Cole, Jim (HP Visual Collaboration R&D) [mailto:jcole@hp.com] > Sent: Wednesday, March 09, 2011 1:19 PM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: RE: [clue] FW: New Version Notification fordraft-romanow-clue- > telepresence-requirements-00 >=20 > Hi, >=20 > Regarding some of the definitions, I wonder to what extent it would be > worth minimizing new terms, and instead extending existing > nomenclatures. Some suggestions along these lines are below, along with > a couple other comments on definitions and the requirements > themselves. >=20 > Regards, > Jim Cole >=20 > 1. "Endpoint" and "Room". What is the difference between an endpoint > and a SIP user agent? Could we use "multistream user agent" instead? > That would give a generic term applicable to phones, desktop > applications, etc. Also, if terms are used interchangeably, would it be > better to try and standardize on one for the purposes of the documents? >=20 > 2. "Layout" and "Source placement". Why have both, since one is aka the > other? Suggest removing Source placement, and just using Layout to > refer to the general task of arranging rendered streams at a receiving > endpoint, whether this means mapping specific streams to specific > displays, or creating a composited (mixed) presentation at the > receiving endpoint. >=20 > 3. "Region". Can this be clarified as to how it differs from field of > view? Would an alternative be to define a spatial metric with which to > describe capture field of view? Perhaps an example would be helpful. >=20 > 4. "Source selection". Seems like this is a special case of the general > mixing function; when streams are not combined. Instead, how about if > we use the well-known term "mixer", and expand it. SIP expanded the > definition from RTP to include non-RTP data. CLUE could likewise expand > the definition to include multistream sessions, which could then > explicitly include the simple case of source selection. >=20 > 5. "Video composite". Following some of the comments above, how about > this simply becoming the output of a multistream mixer? >=20 > 6. REQMT-1. Is there an implied requirement to determine a (synthetic) > spatial relationship between multiple endpoints? >=20 > 7. REQMT-4. Just to be clear, the sender can either be the originating > endpoint, or a middlebox, right? >=20 > 8. REQMT-21. Since this is under "Audio", is it really referring to > lipsync? Or is it a higher-level latency requirement for both audio and > video. Probably need both. >=20 > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Allyn Romanow (allyn) > Sent: Friday, March 04, 2011 9:48 PM > To: clue@ietf.org > Subject: [clue] FW: New Version Notification for draft-romanow-clue- > telepresence-requirements-00 >=20 > Hi Folks, >=20 > I just submitted this first draft of a requirements document. >=20 > Looking forward to your thoughts- >=20 > Allyn >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, March 04, 2011 9:16 PM > To: Allyn Romanow (allyn) > Subject: New Version Notification for draft-romanow-clue-telepresence- > requirements-00 >=20 >=20 > A new version of I-D, draft-romanow-clue-telepresence-requirements- > 00.txt has been successfully submitted by Allyn Romanow and posted to > the IETF repository. >=20 > Filename: draft-romanow-clue-telepresence-requirements > Revision: 00 > Title: Requirements for Telepresence Multi-Streams > Creation_date: 2011-03-05 > WG ID: Independent Submission > Number_of_pages: 11 >=20 > Abstract: > This document discusses the problems, assumptions, and requirements > for handling multiple media streams to enable Telepresence > interoperability. Definitions are also covered here as well. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Mon Mar 14 01:44:15 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4C13A6B1B for ; Mon, 14 Mar 2011 01:44:15 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jr7BTBkoHdb8 for ; Mon, 14 Mar 2011 01:44:14 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 48C1F3A6AF4 for ; Mon, 14 Mar 2011 01:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4644; q=dns/txt; s=iport; t=1300092338; x=1301301938; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=Toycyt9cYUZ2cAtQF3AgZXpD1WNd7SD3IK2d5P6SF74=; b=XFuF8oBpS5yEt8kK0GFcHIoHwvc10pjw/EENGyPfRV1pr0D8CB+piFGN 2CD7bN6bOskc6NmjShdd55KmVg5Kk7Ae78ZCUbsTTGjWfvdP2Y1ByXGFx ip4DDT9fYxk67tRhKixKNJeN943ZCywNaw3O7w1UZGVOzFWRgLB5RlpFu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAC5yfU2tJV2a/2dsb2JhbACEPJQCjGpld6RxixuQAoEng0V2BIUrins X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208";a="225333379" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2011 08:45:37 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2E8jatY005214; Mon, 14 Mar 2011 08:45:36 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); Mon, 14 Mar 2011 01:45:36 -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: Mon, 14 Mar 2011 01:45:24 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03D0F097@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-romanow-clue-telepresence-requirements-01 Thread-Index: AcviIx6ydQE9rtjWQ1qDSCas1trScwAAA1nQ From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 14 Mar 2011 08:45:36.0326 (UTC) FILETIME=[30103660:01CBE224] Subject: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 08:44:15 -0000 Rm9sa3MsIA0KSSBqdXN0IHBvc3RlZCBhbiB1cGRhdGVkIHZlcnNpb24gb2YgdGhlIHJlcXVpcmVt ZW50cyBkcmFmdCwgYmFzZWQgb24gdGhlIGNvbW1lbnRzIEkgZ290IC0gYm90aCBvbiB0aGUgbWFp bGluZyBsaXN0IGFuZCBvZmZsaXN0LiBUaGUgY2hhbmdlcyBhcmUgcHJpbWFyaWx5IHRyeWluZyB0 byBtYWtlIHRoaW5ncyBjbGVhcmVyIGFuZCBjbGVhbiB1cCByZWR1bmRhbmN5LiBBIGlpc3Qgb2Yg dGhlIGNoYW5nZXMgZm9sbG93cyBiZWxvdy4NCg0KVGhhbmtzLA0KQWxseW4NCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRv Omlkc3VibWlzc2lvbkBpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1hcmNoIDE0LCAyMDExIDE6 MzYgQU0NClRvOiBBbGx5biBSb21hbm93IChhbGx5bikNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtcm9tYW5vdy1jbHVlLXRlbGVwcmVzZW5jZS1yZXF1aXJlbWVu dHMtMDEgDQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXJvbWFub3ctY2x1ZS10ZWxl cHJlc2VuY2UtcmVxdWlyZW1lbnRzLTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEFsbHluIFJvbWFub3cgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpGaWxlbmFtZToJIGRyYWZ0LXJvbWFub3ctY2x1ZS10ZWxlcHJlc2VuY2UtcmVxdWlyZW1lbnRz DQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBSZXF1aXJlbWVudHMgZm9yIFRlbGVwcmVzZW5jZSBN dWx0aS1TdHJlYW1zDQpDcmVhdGlvbl9kYXRlOgkgMjAxMS0wMy0xNA0KV0cgSUQ6CQkgSW5kZXBl bmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAxMA0KDQpBYnN0cmFjdDoNClRoaXMg ZG9jdW1lbnQgZGlzY3Vzc2VzIHRoZSBwcm9ibGVtcywgYXNzdW1wdGlvbnMsIGFuZCByZXF1aXJl bWVudHMNCmZvciBoYW5kbGluZyBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zIHRvIGVuYWJsZSBUZWxl cHJlc2VuY2UNCmludGVyb3BlcmFiaWxpdHkuICBEZWZpbml0aW9ucyBhcmUgYWxzbyBjb3ZlcmVk IGhlcmUgYXMgd2VsbC4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdC4NCg0KLS0NCkRFRk5zIOKAkyBwdWxsZWQg4oCccm9vbeKAnSwgYXMgcGVyIGNv bW1lbnQgYnkgSmltIENvbGUuIFVubmVjZXNzYXJ5LCBqdXN0IHVzZSBlbmRwb2ludC4NCg0KRGVs ZXRlZCBzb3VyY2UgcGxhY2VtZW50LCBhcyBwZXIgSmltIENvbGXigJlzIHN1Z2dlc3Rpb24uIHVw ZGF0ZSBsYXlvdXQgd2l0aCBoaXMgdGV4dC4NCg0KUmVnaW9uIOKAkyBhZGRlZCB0aGF0IHRoZSBz ZW5kZXIgZGVmaW5lcyB0aGUgcmVnaW9uLiAgSSBhZ3JlZSB3aXRoIEppbSBDb2xl4oCZcyBjb21t ZW50IHRoYXQgcmVnaW9uIHNob3VsZCBiZSBiZXR0ZXIgZGVmaW5lZC4gSXQgaXMgYW4gaW1wb3J0 YW50IGNvbmNlcHQgZm9yIHRoZSBtb2RlbCwgYSBkcmFmdCBvZiB3aGljaCB3aWxsIGNvbWUgb3V0 IHNob3J0bHkuICBMZXTigJlzIHVwZGF0ZSB0aGUgcmVnaW9uIGRlZmluaXRpb24gaW4gbGlnaHQg b2YgdGhhdCBsYXRlci4NCg0KU291cmNlIHNlbGVjdGlvbi4gSmltIENvbGUgc3VnZ2VzdGVkIHNo b3VsZCBiZSByZXBsYWNlZCBieSBhbiBleHRlbmRlZCBkZWZpbml0aW9uIG9mIG1peGluZyB0byBp bmNsdWRlIG11bHRpc3RyZWFtLiAgRGlzY3Vzc2lvbnMgb2YgbWl4aW5nIHNlZW0gYWxzbyB0byBp bmNsdWRlIGhvdyB0byB1c2UgU1NSQyBhbmQgQ1NSQyBmaWVsZHMuIEl0IHdvdWxkIHByZW1hdHVy ZSBmb3IgdXMgYXQgdGhpcyBwb2ludCB0byBtYWtlIHRob3NlIGtpbmRzIG9mIHNvbHV0aW9uLWJh c2VkIGFzc3VtcHRpb25zLiBTbywgSSBwcm9wb3NlIHdhaXRpbmcgYSBiaXQgdG8gZml4IHRoaXMu ICBXZSBjYW4gZGlzY3Vzcy4NCg0KVmlkZW8gY29tcG9zaXRlIC0gU2FtZSBhcyBhYm92ZS4gTGlr ZWQgdGhlIGltcHJvdmVtZW50LCBidXQgc3VnZ2VzdCB3YWl0LiANCg0KRGVsZXRlIGFzc3VtcHRp b24gOSANCk9mZmxpc3QgY29tbWVudCBzdWdnZXN0ZWQgdGhhdCBTRFAgY2FuIHNpZ25hbCB0aGUg cmFuZ2Ugb2YgcmVzb2x1dGlvbnMuIEluIGFueSBjYXNlLCBJIGJlbGlldmUgdGhpcyBpcyBhIGdl bmVyYWxseSBoZWxkIGFzc3VtcHRpb24gYWJvdXQgZGVjb2RlcnMsIGFuZCBpdCBwcm9iYWJseSBp cyBub3QgbmVjZXNzYXJ5IGhlcmUuIA0KDQoNClJFcW10IDEg4oCTIGNoYW5nZWQg4oCcc3BhdGlh bOKAnSBpbmZvcm1hdGlvbiB0byDigJxsYXlvdXTigJ0gaW5mb3JtYXRpb24sIHdoaWNoIGlzIG1v cmUgYWNjdXJhdGUgYW5kIGhvcGVmdWxseSBtb3JlIHVuZGVyc3RhbmRhYmxlLg0KDQpSZXFtdCAz IOKAkyBkZWxldGVkLCByZWR1bmRhbnQuIENvdmVyZWQgaW4gcmVxbXQgNyB3aGljaCBpcyBtb3Jl IGdlbmVyYWwNCg0KUmVxbXQgNC4gQWRkZWQgbW9yZSBkZXNjcmlwdGlvbiB0byBhIHJlY2VpdmVy IGFza2luZyBmb3Igc3RyZWFtcyBmcm9tIGEgc2VuZGVyIOKAkyBpbiByZXNwb25zZSB0byBjb21t ZW50IGZyb20gSmltIENvbGUgYW5kIGFuIG9mZmxpbmUgY29tbWVudA0KDQpSZXFtdCAgNi4gRGVs ZXRlZCBzdXBwb3J0IGZvciBCYXNlbGluZSAyNjQuIFRoaXMgaXMgbW9yZSBvZiBhIHByb2ZpbGUg c3BlY2lmaWNhdGlvbiwgbm90IHBhcnQgb2YgcHJvdG9jb2wuIA0KDQpSZXFtdCAxMSDigJMgZGVs ZXRlZC4gQmFzZWQgb24gb2ZmbGluZSBjb21tZW50LCBpdOKAmXMgbW9yZSBvZiBhIHNvbHV0aW9u IHRoYW4gYSByZXF1aXJlbWVudC4NCg0KUmVxbXQgMTIgZGVsZXRlZC4gTW9yZSBvZiBhIHNvbHV0 aW9uIHRoYW4gYSByZXF1aXJlbWVudCwgb2ZmbGluZSBjb21tZW50DQoNClJlcW10IDEzIOKAkyBh Z3JlZSB0aGF0IGl0IHNlZW1zIHJlbGF0ZWQgdG8gZHluYW1pY2FsbHkgY29taW5nIGFuZCBnb2lu ZyBzdHJlYW1zLiBNb3ZlZCBpdC4NCg0KUmVxbXQgMTQg4oCTIG1lcmdlZCBpbnRvIFJlcW10IDEu IEl0IHdhcyByZWR1bmRhbnQuDQoNClJlcW10IDE1LiBNZXJnZWQgaW50byBSZXFtdCAyIGFib3V0 IHN1cHBvcnQgZm9yIGR5bmFtaWMgYmVoYXZpb3Igb2Ygc3RyZWFtcy4gUGFydCB3YXMgYWxzbyBt b3JlIGFib3V0IHNvbHV0aW9uIHRoYW4gcmVxdWlyZW1lbnQsIHJlbW92ZWQuDQoNClJlcW10IDE2 LiBNb3ZlZCB0byBzdWJzZXQgb2YgIzIsIGFuZCByZW1vdmVkIHNvbWUgYXMgaXQgd2FzIG1vcmUg b2YgYSBzb2x1dGlvbiB0aGFuIHJlcXVpcmVtZW50LiBPZmZsaW5lIGNvbW1lbnQNCg0KUmVxbXQg MTcg4oCTIGRlbGV0ZWQuIFNhbWUgYXMgMTgNCg== From allyn@cisco.com Mon Mar 14 01:45:20 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B16A93A6AF4 for ; Mon, 14 Mar 2011 01:45:20 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPfS-09PIkKb for ; Mon, 14 Mar 2011 01:45:19 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BC6673A6C31 for ; Mon, 14 Mar 2011 01:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=886; q=dns/txt; s=iport; t=1300092403; x=1301302003; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=huo9YdtbMXCk6FptpecThyAvKBH89eyqhwxlaDSTXiM=; b=PXmSH4GcZEkBcMK2sYHpaIaAmd705CZ58CDrVhs3rKYRpz56VHJ6bD6J rV3F/C+82iG2svS6jSdb86/12VNj2unLCeAhLs3ncyvrb0HQz2j3VRkGm 3OBXSaKDUVPnrI580OOVu4J42LTDM6lrYskSvDs7fpZlBKJQGzXsM+ceF c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAOJyfU2tJV2c/2dsb2JhbACYPo1Qd6Rzmx2FYgSFK4p7 X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208";a="345748814" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 08:46:42 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2E8kgN6003464; Mon, 14 Mar 2011 08:46:42 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); Mon, 14 Mar 2011 01:46:41 -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: Mon, 14 Mar 2011 01:46:39 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03D0F098@xmb-sjc-221.amer.cisco.com> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948FA9C1E@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Telepresence requirements: Endpoint definition [was: New Version Notification for draft-romanow-clue-telepresence-requirements-00] Thread-Index: Acva9KFK4CNwOGOkSXyP3pkHEpVuyQAAiujQAKV80cABJc4zMA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05851948FA9C1E@ESESSCMS0356.eemea.ericsson.se> From: "Allyn Romanow (allyn)" To: "Christer Holmberg" , X-OriginalArrivalTime: 14 Mar 2011 08:46:41.0840 (UTC) FILETIME=[571CDB00:01CBE224] Subject: Re: [clue] Telepresence requirements: Endpoint definition [was: New Version Notification for draft-romanow-clue-telepresence-requirements-00] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 08:45:20 -0000 Hi Christer,=20 The reference to room has been deleted, and the requirements are pretty explicit about including hand held devices, so I hope this will be clear now. Thanks, Allyn > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, March 08, 2011 4:35 AM > To: Allyn Romanow (allyn); clue@ietf.org > Subject: Telepresence requirements: Endpoint definition [was: New > Version Notification for draft-romanow-clue-telepresence-requirements- > 00] >=20 >=20 > Hi, >=20 > A comment on the "Endpoint" definition. >=20 > It talks about "end system", and also refers to the "Room" definition, > which at least to me relates to telepresence rooms etc. >=20 > But, I assume it also covers normal phones, hand held devices etc. I > guess it would be good to mention that. >=20 > Regards, >=20 > Christer From allyn@cisco.com Mon Mar 14 01:48:30 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841073A6B99 for ; Mon, 14 Mar 2011 01:48:30 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y6JjdXhkE+l for ; Mon, 14 Mar 2011 01:48:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 7E5663A6AF4 for ; Mon, 14 Mar 2011 01:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=2271; q=dns/txt; s=iport; t=1300092593; x=1301302193; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=m0/qQhsJMLU1jfhGjClIqwok+f9CSa0g2we9/TzIbjY=; b=f4Oo7a7gkOtOOLnVDxj0MA3V2bGAYrpzEpw2Wq8SIAbZi1Ko/s2At1sv l1ew9y9EBqNtXRnXRZ+QrJ+uTsdzvSBrOuPEkCgu1hvHI8D9dOAaqqJhu f98tZ+o1/vsgQ+Nk7uZcFrtBSNjr3WEVXsdp4+6UzFGS+88XMftm/Sm2H w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAANNzfU2tJXG8/2dsb2JhbACYPo1Qd6Rrmx+FYgSFK4p7 X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208";a="320013639" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-2.cisco.com with ESMTP; 14 Mar 2011 08:49:51 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2E8npGS027786; Mon, 14 Mar 2011 08:49:51 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); Mon, 14 Mar 2011 01:49:50 -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: Mon, 14 Mar 2011 01:49:47 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03D0F099@xmb-sjc-221.amer.cisco.com> In-Reply-To: <80E9B992-5363-44CF-9741-63ACB5FC2BB5@magorcorp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00 Thread-Index: AcvdASiRsBiQenYlR2KYIYL8WriPKQFI0tCQ References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> <80E9B992-5363-44CF-9741-63ACB5FC2BB5@magorcorp.com> From: "Allyn Romanow (allyn)" To: "Peter Musgrave" X-OriginalArrivalTime: 14 Mar 2011 08:49:50.0617 (UTC) FILETIME=[C7A1F090:01CBE224] Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-telepresence-requirements-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 08:48:30 -0000 Hi Peter, Responses below- > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Monday, March 07, 2011 11:52 AM > To: Allyn Romanow (allyn) > Cc: clue@ietf.org > Subject: Re: [clue] FW: New Version Notification for draft-romanow- > clue-telepresence-requirements-00 >=20 > Hi Allyn, >=20 > Overall this is big step forward. Thanks. >=20 > A couple of quick comments (I still need to re-read carefully) >=20 > RQMT-6: Support for H.264 baseline > This feels a bit like a media profile (and there is no corresponding > one for audio). I suspect this is out of scope - since CLUE is about > semantics of streams and not requirements as to what CODEC be used... Yep, my bad. I removed it. >=20 > RQMT-12 talks about SDP streams. Should this say RTP streams? Removed 12. I felt it was more of a solution than a requirent. >=20 > Regards, >=20 > Peter Musgrave >=20 >=20 > On 2011-03-05, at 12:47 AM, Allyn Romanow (allyn) wrote: >=20 > > Hi Folks, > > > > I just submitted this first draft of a requirements document. > > > > Looking forward to your thoughts- > > > > Allyn > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Friday, March 04, 2011 9:16 PM > > To: Allyn Romanow (allyn) > > Subject: New Version Notification for draft-romanow-clue- > telepresence-requirements-00 > > > > > > A new version of I-D, draft-romanow-clue-telepresence-requirements- > 00.txt has been successfully submitted by Allyn Romanow and posted to > the IETF repository. > > > > Filename: draft-romanow-clue-telepresence-requirements > > Revision: 00 > > Title: Requirements for Telepresence Multi-Streams > > Creation_date: 2011-03-05 > > WG ID: Independent Submission > > Number_of_pages: 11 > > > > Abstract: > > This document discusses the problems, assumptions, and requirements > > for handling multiple media streams to enable Telepresence > > interoperability. Definitions are also covered here as well. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue From allyn@cisco.com Mon Mar 14 01:52:51 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79A4E3A6C3E for ; Mon, 14 Mar 2011 01:52:51 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBjOyQJSbXiP for ; Mon, 14 Mar 2011 01:52:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 548EA3A6BEC for ; Mon, 14 Mar 2011 01:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3068; q=dns/txt; s=iport; t=1300092853; x=1301302453; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=28R6tnfuNjCL/5Gsh4x6CDv/pXdo0JWOkahG1PhCykI=; b=l3I413PzVG9q9VixXPMR8r9ugeN19FDUW5oq18JD1HJn31CoTdcbTuN7 nCbd7hlTAh/vHvuiTK/Cg6NUN1BiaD44LlpIzMAft1zH3CfCl7gsVOqc0 IE/Fxgj6trVLEJ3fRiSS9ps0GV0a4XPYNYfG+GACarqU3lCApBYnhmvNs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANNzfU2tJXHA/2dsb2JhbACmDneka5sfhWIEhSuKew X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208";a="666897839" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-6.cisco.com with ESMTP; 14 Mar 2011 08:54:13 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2E8sCO3000459; Mon, 14 Mar 2011 08:54:12 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 01:54:12 -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: Mon, 14 Mar 2011 01:54:07 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03D0F09A@xmb-sjc-221.amer.cisco.com> In-Reply-To: <057BEE3C39FE5D48ADBD41D1DE16022C197EBB4642@GVW0673EXC.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] FW: New Version Notification fordraft-romanow-clue-telepresence-requirements-00 Thread-Index: Acva9KFK4CNwOGOkSXyP3pkHEpVuyQAAiujQAOnR+WAA4bCmIA== References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03BBBBE0@xmb-sjc-221.amer.cisco.com> <057BEE3C39FE5D48ADBD41D1DE16022C197EBB4642@GVW0673EXC.americas.hpqcorp.net> From: "Allyn Romanow (allyn)" To: "Cole, Jim (HP Visual Collaboration R&D)" X-OriginalArrivalTime: 14 Mar 2011 08:54:12.0601 (UTC) FILETIME=[63C98690:01CBE225] Cc: clue@ietf.org Subject: Re: [clue] FW: New Version Notification fordraft-romanow-clue-telepresence-requirements-00 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 14 Mar 2011 08:52:51 -0000 HI Jim, Thanks for your good comments. Responses inline below 1. "Endpoint" and "Room". What is the difference between an endpoint and a SIP=20 user agent? Could we use "multistream user agent" instead? That would give a=20 generic term applicable to phones, desktop applications, etc. Also, if terms=20 are used interchangeably, would it be better to try and standardize on one for=20 the purposes of the documents? you're right. deleted room. 2. "Layout" and "Source placement". Why have both, since one is aka the other?=20 Suggest removing Source placement, and just using Layout to refer to the general task of arranging rendered streams at a receiving endpoint, whether=20 this means mapping specific streams to specific displays, or creating a=20 composited (mixed) presentation at the receiving endpoint. yes. deleted source placement and used your words in dfn of layout. thanks 3. "Region". Can this be clarified as to how it differs from field of view?=20 Would an alternative be to define a spatial metric with which to describe=20 capture field of view? Perhaps an example would be helpful. yes, you're right. Region is used in the design or model draft which will be sent out in about a week.=20 working on it also). I can't think how to fix this right at the moment, in time to get it into the next draft due tomorrow. But i think that once we consider the design doc, we can definitely improve this. It is a key concept. 4. "Source selection". Seems like this is a special case of the general mixing=20 function; when streams are not combined. Instead, how about if we use the=20 well-known term "mixer", and expand it. SIP expanded the definition from RTP=20 to include non-RTP data. CLUE could likewise expand the definition to include=20 multistream sessions, which could then explicitly include the simple case of=20 source selection. I think this and the following comment are good ideas. However, I'm not yet sure how we want to use the RTP mixer concept since it includes how it is to be implemented with SSRC and CSRC. It seems to me a bit premature to assume things that have to to with solutions. So, let's hold off on this pending solution discussion. okay? 5. "Video composite". Following some of the comments above, how about this=20 simply becoming the output of a multistream mixer? see last comment 6. REQMT-1. Is there an implied requirement to determine a (synthetic) spatial=20 relationship between multiple endpoints? Sorry, i did not understand this comment. I changed "spatial" information to "layout" information. However, perhaps you could further explain this to me.=20 7. REQMT-4. Just to be clear, the sender can either be the originating=20 endpoint, or a middlebox, right? yes. I added this to the text. 8. REQMT-21. Since this is under "Audio", is it really referring to lipsync?=20 Or is it a higher-level latency requirement for both audio and video. Probably=20 need both. I'm not sure what you mean. We should discuss.=20 From magnus.westerlund@ericsson.com Tue Mar 22 07:41:05 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1473A6862 for ; Tue, 22 Mar 2011 07:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.513 X-Spam-Level: X-Spam-Status: No, score=-106.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qANW1SRB+JeQ for ; Tue, 22 Mar 2011 07:41:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 135F83A685B for ; Tue, 22 Mar 2011 07:41:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-cc-4d88b55ccbf2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 25.77.21265.C55B88D4; Tue, 22 Mar 2011 15:42:36 +0100 (CET) Received: from [153.88.17.206] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Tue, 22 Mar 2011 15:42:36 +0100 Message-ID: <4D88B55B.80902@ericsson.com> Date: Tue, 22 Mar 2011 15:42:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: CLUE , "allyn@cisco.com" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Subject: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 22 Mar 2011 14:41:05 -0000 Hi, When reviewing draft-romanow-clue-telepresence-requirements-01 I realized that it has no requirements on that the system supports adaptation of the media streams. There are two aspects of this I see that are related but have separate purposes and therefore warrants two different requirements. Media Adaptation Requirements: ReqX: The Telepresence system needs to have congestion control of the media streams. ReqX+1: Dynamic Control of sources' encoding of a media stream, in such aspects as video frame-rate, bit-rate upper limit, temporal spatial quality trade-off, resolution, Full Intra Request, Picture Loss Indicator, etc. Motivation: Congestion Control is needed to enable Telepresence systems to work also over network paths that doesn't provide QoS guarantees or when QoS guarantees fails. This problem is well studied for peer to peer applications. With an RTP mixer in a multi-party conference session then this gets more complexed as one needs to consider both what can be accomplished in the media source to the RTP mixer direction, and then from the mixer to each of the other participants. This requires some control of the media encoding in the sources by the RTP mixer to ensure that the media provided is as useful as possible. The second requirement is based on the need to enable a conference mixer to maximize the medias usability for the participants. There are several aspects here: - FIR for switching of video streams - Bit-rate upper limit to adapt media stream to suit mixer to participant direction. - PLI to enable a participant with broken decoder state to get that cleaned up. - Frame-rate to adapt to receiver capabilities or change purpose of a media stream. - Temporal Spatial Trade-off if one wants to control video encoders to prefer frame rate over spatial quality or the other way around. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephane.cazeaux@orange-ftgroup.com Wed Mar 23 10:09:20 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 720D83A693A for ; Wed, 23 Mar 2011 10:09:20 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiS4uTqP1-zx for ; Wed, 23 Mar 2011 10:09:19 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 31B3A3A6938 for ; Wed, 23 Mar 2011 10:09:19 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F63D858003 for ; Wed, 23 Mar 2011 18:16:47 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 0A30C778002 for ; Wed, 23 Mar 2011 18:16:47 +0100 (CET) Received: from ftrdhub2.rd.francetelecom.fr ([10.193.109.194]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Mar 2011 18:10:52 +0100 Received: from FTRDCH02.rd.francetelecom.fr (10.194.32.13) by ftrdhub2.rd.francetelecom.fr (10.193.109.194) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 23 Mar 2011 18:10:51 +0100 Received: from FTRDMB01.rd.francetelecom.fr ([fe80::b5e9:4a4e:d949:60b7]) by FTRDCH02.rd.francetelecom.fr ([::1]) with mapi id 14.01.0270.001; Wed, 23 Mar 2011 18:10:51 +0100 From: To: Thread-Topic: Comments on use cases Thread-Index: Acvpe0srzUVRcf/jTC2S9nx3IgbWpA== Date: Wed, 23 Mar 2011 17:10:50 +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.87] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 23 Mar 2011 17:10:52.0880 (UTC) FILETIME=[43DAFD00:01CBE97D] Subject: [clue] Comments on use cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2011 17:09:20 -0000 Hi, After review of draft-romanow-clue-telepresence-use-cases-01.txt, below are= some comments about use cases that we may want to consider, and about some= needed clarifications. 1. Ad-hoc multi-stream telepresence room use case We may want to define a use case where a multi-stream telepresence room is = dynamically constituted of multiple mono-stream endpoints. The telepresence= room becomes an ad-hoc multi-stream telepresence room because we rely on e= ndpoints that have been dynamically associated to provide the multi-stream = experience. A good example is a multi-stream telepresence room constituted of several h= andheld telepresence devices (all being mono-stream by nature). =09 NOTE: The terms "room" and "endpoint" are considered as interchangeable in = draft-romanow-clue-telepresence-requirements-01.txt. This point changes thi= s definition, since a room could be constituted of multiple endpoints. 2. "1 to n" multipoint conference use case Basically, the sections 4.1 and 4.2 of draft-romanow-clue-telepresence-use-= cases-01.txt correspond to a "1 to 1" meeting. The section 4.3 corresponds = to a "n" meeting. We may want to add the "1 to n" use case. Examples of such use case could be remote training, university course, busi= ness meeting like "director's speech to employees", etc... Finally, this new use is a generic version of the section 4.6, which is a (= very sophisticated) sample of "1 to n" meeting.=20 We can consider the following characteristics for this use case (not exhaus= tive): * Distinction between main site (the main speaker) and remote sites (the pa= rticipants) * Multi-stream usage, more or less for the same principles as the ones desc= ribe in 4.6: remote sites always see the main site, remote sites and main s= ite see a participant asking a question, etc. * A remote site can ask for the word. The main site will see which site req= uests to take floor, and can choose to give the floor to a site. In other t= erms, this use case clarifies the need for a main site to control layout an= d received streams on the remote sites, in a more general manner than the s= ample of the section 4.6. * Conference topology discovery (who is in the conference, and configuratio= n/capability of each site), which could be displayed on the main site to he= lp the user to make audio/video selection (user choice). 3. Collaboration This draft seems to restrict the collaboration (or presentation) to the usa= ge of video as the only mean of sharing information. Why shall it be restri= cted here? In the context of telepresence where the target is (among others) the high = quality of the experience, the solution of video for data collaboration is = not the best, especially for technical document sharing. Using video lowers= quality, requires bandwidth and does not allow participants to take contro= l of the document in turns. We should consider the video as one mean. And take into account the necessi= ty of high quality experience to consider integrating and/or defining other= means? 4. Heterogeneous systems The section 4.5 about heterogeneous systems is confusing. In particular the= sentence "We are not here talking about legacy systems, but rather systems= built to participate in such a conference, although they are single stream= only", which seems to exclude support for legacy systems? It shall be clarified what "heterogeneous systems" means. Can heterogeneous systems be defined as being constituted of: * Endpoints with different configurations: not the same number of screens, = cameras, microphones, loudspeaker * Endpoints with different capabilities: not the same configuration + not t= he same available bandwidth, screen size, endpoint size, access network, CP= U power, etc. * Legacy (aka. traditional) endpoints: non-standard endpoints (as stated in= the charter) are excluded from this category. This remark is also valid to draft-romanow-clue-telepresence-requirements-0= 1.txt which talks of heterogeneous systems without defining them clearly. Regards, Stephane Cazeaux -- St=E9phane Cazeaux Orange Labs +33 2 31 75 95 40 stephane.cazeaux@orange-ftgroup.com From ron.even.tlv@gmail.com Wed Mar 23 11:28:23 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054FE28C10B for ; Wed, 23 Mar 2011 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-POs4-qxNr2 for ; Wed, 23 Mar 2011 11:28:21 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1D4D328C0D6 for ; Wed, 23 Mar 2011 11:28:20 -0700 (PDT) Received: by ewy19 with SMTP id 19so2668629ewy.31 for ; Wed, 23 Mar 2011 11:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=9DIh30+0IurHIP9YjCJ310TUhrMV/Gc52l4wwBdlyCA=; b=xbm3wf6nXuwqZw60JpytePKwzwEoJkrChIHAv2xWkva7qlljXbLBAf8svpIsZ4WztN Fcr2cDtmMb1FViw3RYyhbgjO1xLKSoP4Oo7hfHDUda49n4viJvRZMN9Lom7aVaM+Tyvb oMcMmoGgHHmJ3mDV9vl7EeQ5n7npRrE8JS8AU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=nHDmKlpmXAEj5ouUvX0jbDyWbpaQTjudvUcfnRuPqgq9D4MRHON4ETg+Zs7y6s5/Kr 5QogginrrODXN0Hu53Jcl2dYWusAGPinA+t0ltttP1w8+aXWWV4nK1A5Ae2YNEoOpwM5 Bctiel/XpHceW9fJ4Gm7kDQ8osyh0u3izE6U0= Received: by 10.14.122.205 with SMTP id t53mr2707641eeh.106.1300904994251; Wed, 23 Mar 2011 11:29:54 -0700 (PDT) Received: from windows8d787f9 (cust.static.109-164-246-172.swisscomdata.ch [109.164.246.172]) by mx.google.com with ESMTPS id w59sm3876802eeh.17.2011.03.23.11.29.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2011 11:29:53 -0700 (PDT) From: "Roni Even" To: , References: In-Reply-To: Date: Wed, 23 Mar 2011 20:29:34 +0200 Message-ID: <4d8a3c21.537c0e0a.28be.ffffe482@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvpe0srzUVRcf/jTC2S9nx3IgbWpAAC+fbQ Content-Language: en-us Subject: Re: [clue] Comments on use cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 23 Mar 2011 18:28:23 -0000 Hi, See my comments inline Roni Even > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of > stephane.cazeaux@orange-ftgroup.com > Sent: Wednesday, March 23, 2011 7:11 PM > To: clue@ietf.org > Subject: [clue] Comments on use cases >=20 > Hi, >=20 > After review of draft-romanow-clue-telepresence-use-cases-01.txt, = below > are some comments about use cases that we may want to consider, and > about some needed clarifications. >=20 > 1. Ad-hoc multi-stream telepresence room use case >=20 > We may want to define a use case where a multi-stream telepresence = room > is dynamically constituted of multiple mono-stream endpoints. The > telepresence room becomes an ad-hoc multi-stream telepresence room > because we rely on endpoints that have been dynamically associated to > provide the multi-stream experience. > A good example is a multi-stream telepresence room constituted of > several handheld telepresence devices (all being mono-stream by > nature). >=20 > NOTE: The terms "room" and "endpoint" are considered as = interchangeable > in draft-romanow-clue-telepresence-requirements-01.txt. This point > changes this definition, since a room could be constituted of multiple > endpoints. I understand that this case involve multiple call set up and some need = for co-relation between the multiple end points which do not have a central management entity. I am not sure that this use case is in the scope. I = can understand one endpoint making multiple calls but not this case.=20 >=20 >=20 > 2. "1 to n" multipoint conference use case > Basically, the sections 4.1 and 4.2 of = draft-romanow-clue-telepresence- > use-cases-01.txt correspond to a "1 to 1" meeting. The section 4.3 > corresponds to a "n" meeting. We may want to add the "1 to n" use = case. > Examples of such use case could be remote training, university course, > business meeting like "director's speech to employees", etc... > Finally, this new use is a generic version of the section 4.6, which = is > a (very sophisticated) sample of "1 to n" meeting. >=20 > We can consider the following characteristics for this use case (not > exhaustive): > * Distinction between main site (the main speaker) and remote sites > (the participants) > * Multi-stream usage, more or less for the same principles as the ones > describe in 4.6: remote sites always see the main site, remote sites > and main site see a participant asking a question, etc. > * A remote site can ask for the word. The main site will see which = site > requests to take floor, and can choose to give the floor to a site. In > other terms, this use case clarifies the need for a main site to > control layout and received streams on the remote sites, in a more > general manner than the sample of the section 4.6. > * Conference topology discovery (who is in the conference, and > configuration/capability of each site), which could be displayed on = the > main site to help the user to make audio/video selection (user = choice). I think that is a subset of multipoint which is application driven. What = is known as "lecture mode". The addition is the floor control that is part = of the conference. The participant switching is application driven. >=20 >=20 > 3. Collaboration >=20 > This draft seems to restrict the collaboration (or presentation) to = the > usage of video as the only mean of sharing information. Why shall it = be > restricted here? >=20 > In the context of telepresence where the target is (among others) the > high quality of the experience, the solution of video for data > collaboration is not the best, especially for technical document > sharing. Using video lowers quality, requires bandwidth and does not > allow participants to take control of the document in turns. >=20 > We should consider the video as one mean. And take into account the > necessity of high quality experience to consider integrating and/or > defining other means? Data collaboration is important but can suggest a standard data collaboration protocol. >=20 >=20 > 4. Heterogeneous systems >=20 > The section 4.5 about heterogeneous systems is confusing. In = particular > the sentence "We are not here talking about legacy systems, but rather > systems built to participate in such a conference, although they are > single stream only", which seems to exclude support for legacy = systems? > It shall be clarified what "heterogeneous systems" means. >=20 > Can heterogeneous systems be defined as being constituted of: > * Endpoints with different configurations: not the same number of > screens, cameras, microphones, loudspeaker > * Endpoints with different capabilities: not the same configuration + > not the same available bandwidth, screen size, endpoint size, access > network, CPU power, etc. > * Legacy (aka. traditional) endpoints: non-standard endpoints (as > stated in the charter) are excluded from this category. >=20 > This remark is also valid to draft-romanow-clue-telepresence- > requirements-01.txt which talks of heterogeneous systems without > defining them clearly. >=20 >=20 >=20 > Regards, > Stephane Cazeaux >=20 >=20 > -- > St=E9phane Cazeaux > Orange Labs > +33 2 31 75 95 40 > stephane.cazeaux@orange-ftgroup.com >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From aravind.sethuraman@teliris.com Thu Mar 24 19:11:17 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31B103A67AA for ; Thu, 24 Mar 2011 19:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+8SNeBJCx0C for ; Thu, 24 Mar 2011 19:11:10 -0700 (PDT) Received: from imta-38.everyone.net (imta-35.everyone.net [216.200.145.35]) by core3.amsl.com (Postfix) with ESMTP id AE4F83A67B0 for ; Thu, 24 Mar 2011 19:11:07 -0700 (PDT) Received: from pps.filterd (omta006 [127.0.0.1]) by imta-38.everyone.net (8.14.4/8.14.4) with SMTP id p2P2C9qp001642; Thu, 24 Mar 2011 19:12:40 -0700 Received: from dm0226.mta.everyone.net (lb009-10-float.sj2.proofpoint.com [172.16.0.1]) by imta-38.everyone.net with ESMTP id v8hep8b3j-1; Thu, 24 Mar 2011 19:12:40 -0700 X-Eon-Dm: dm0226 Received: by dm0226.mta.everyone.net (EON-AUTHRELAY2 - 457f155b) id dm0226.4d855a0e.a0376; Thu, 24 Mar 2011 19:12:39 -0700 X-Eon-Sig: AQLO6zJNi/oXWIfwUQIAAAAD,56d31d14406841694457a63624fe5d1b Date: Thu, 24 Mar 2011 22:12:38 -0400 From: Aravind Sethuraman To: Roni Even Message-ID: <9FE4B720DA5B404F916200F0B6ACD4CD@teliris.com> In-Reply-To: <4d8a3c21.537c0e0a.28be.ffffe482@mx.google.com> References: <4d8a3c21.537c0e0a.28be.ffffe482@mx.google.com> X-Mailer: sparrow 1.1 (build 677) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4d8bfa16_1e7ff521_a99" Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1103240170 Cc: clue@ietf.org Subject: Re: [clue] Comments on use cases X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 25 Mar 2011 02:11:18 -0000 --4d8bfa16_1e7ff521_a99 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Content-Disposition: inline hello all, 1.can we not define endpoint or a room to be the entity that comprises of spatially related end points but at a given time will participate in a single telepresence call? (conference/conversation etc). I doubt there will be a case where say a 3 screen room, 2 screens will be in a separate telepresence call and the presentation will be in another telepresence call. And it is important to delineate between a telepresence call WITH setting up SIP session, ie, in a single telepresence call , there could be N SIP sessionbs established. Therefore, a room and endpoint,imho, should not be thought of as different but a room is a type of endpoint. 2. I do not know why should there be a necessary of classifying a main speaker. It can be a type of call in which certain endpoints are only in send only mode and others are in receive only mode (along with the 3rd mode, Send and Receive). As Roni correctly said, it is a subset of application driven multipoint. my 2 cents... Aravind Sethuraman Chief Software Architect Teliris, Inc. | 55 Broadway, 14th Floor, New York, NY 10006 | C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869 | AIM aravindsraman On Thursday, March 24, 2011 at 9:44 PM, Roni Even wrote: > Hi, > See my comments inline > Roni Even > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > stephane.cazeaux@orange-ftgroup.com > > Sent: Wednesday, March 23, 2011 7:11 PM > > To: clue@ietf.org > > Subject: [clue] Comments on use cases > > > > Hi, > > > > After review of draft-romanow-clue-telepresence-use-cases-01.txt, below > > are some comments about use cases that we may want to consider, and > > about some needed clarifications. > > > > 1. Ad-hoc multi-stream telepresence room use case > > > > We may want to define a use case where a multi-stream telepresence room > > is dynamically constituted of multiple mono-stream endpoints. The > > telepresence room becomes an ad-hoc multi-stream telepresence room > > because we rely on endpoints that have been dynamically associated to > > provide the multi-stream experience. > > A good example is a multi-stream telepresence room constituted of > > several handheld telepresence devices (all being mono-stream by > > nature). > > > > NOTE: The terms "room" and "endpoint" are considered as interchangeable > > in draft-romanow-clue-telepresence-requirements-01.txt. This point > > changes this definition, since a room could be constituted of multiple > > endpoints. > I understand that this case involve multiple call set up and some need for > co-relation between the multiple end points which do not have a central > management entity. I am not sure that this use case is in the scope. I can > understand one endpoint making multiple calls but not this case. > > > > > > > 2. "1 to n" multipoint conference use case > > Basically, the sections 4.1 and 4.2 of draft-romanow-clue-telepresence- > > use-cases-01.txt correspond to a "1 to 1" meeting. The section 4.3 > > corresponds to a "n" meeting. We may want to add the "1 to n" use case. > > Examples of such use case could be remote training, university course, > > business meeting like "director's speech to employees", etc... > > Finally, this new use is a generic version of the section 4.6, which is > > a (very sophisticated) sample of "1 to n" meeting. > > > > We can consider the following characteristics for this use case (not > > exhaustive): > > * Distinction between main site (the main speaker) and remote sites > > (the participants) > > * Multi-stream usage, more or less for the same principles as the ones > > describe in 4.6: remote sites always see the main site, remote sites > > and main site see a participant asking a question, etc. > > * A remote site can ask for the word. The main site will see which site > > requests to take floor, and can choose to give the floor to a site. In > > other terms, this use case clarifies the need for a main site to > > control layout and received streams on the remote sites, in a more > > general manner than the sample of the section 4.6. > > * Conference topology discovery (who is in the conference, and > > configuration/capability of each site), which could be displayed on the > > main site to help the user to make audio/video selection (user choice). > > I think that is a subset of multipoint which is application driven. What is > known as "lecture mode". The addition is the floor control that is part of > the conference. The participant switching is application driven. > > > > > > 3. Collaboration > > > > This draft seems to restrict the collaboration (or presentation) to the > > usage of video as the only mean of sharing information. Why shall it be > > restricted here? > > > > In the context of telepresence where the target is (among others) the > > high quality of the experience, the solution of video for data > > collaboration is not the best, especially for technical document > > sharing. Using video lowers quality, requires bandwidth and does not > > allow participants to take control of the document in turns. > > > > We should consider the video as one mean. And take into account the > > necessity of high quality experience to consider integrating and/or > > defining other means? > > Data collaboration is important but can suggest a standard data > collaboration protocol. > > > > > > > 4. Heterogeneous systems > > > > The section 4.5 about heterogeneous systems is confusing. In particular > > the sentence "We are not here talking about legacy systems, but rather > > systems built to participate in such a conference, although they are > > single stream only", which seems to exclude support for legacy systems? > > It shall be clarified what "heterogeneous systems" means. > > > > Can heterogeneous systems be defined as being constituted of: > > * Endpoints with different configurations: not the same number of > > screens, cameras, microphones, loudspeaker > > * Endpoints with different capabilities: not the same configuration + > > not the same available bandwidth, screen size, endpoint size, access > > network, CPU power, etc. > > * Legacy (aka. traditional) endpoints: non-standard endpoints (as > > stated in the charter) are excluded from this category. > > > > This remark is also valid to draft-romanow-clue-telepresence- > > requirements-01.txt which talks of heterogeneous systems without > > defining them clearly. > > > > > > > > Regards, > > Stephane Cazeaux > > > > > > -- > > Stéphane Cazeaux > > Orange Labs > > +33 2 31 75 95 40 > > stephane.cazeaux@orange-ftgroup.com > > > > > > _______________________________________________ > > 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 > --4d8bfa16_1e7ff521_a99 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
hello all,
1.can we not defi= ne endpoint or a room to be the entity that comprises of spatially relate= d end points but at a given time will participate in a single telepresenc= e call=3F (conference/conversation etc). I doubt there will be a case whe= re say a 3 screen room, 2 screens will be in a separate telepresence call= and the presentation will be in another telepresence call.  And it = is important to delineate between a telepresence call WITH setting up SIP= session, ie, in a single telepresence call , there could be N SIP sessio= nbs established. Therefore, a room and endpoint,imho, should not be thoug= ht of as different but a room is a type of endpoint.

2. I do not know why should there be a neces= sary of classifying a main speaker. It can be a type of call in which cer= tain endpoints are only in send only mode and others are in receive only = mode (along with the 3rd mode, Send and Receive). As Roni correctly said,= it is a subset of application driven multipoint.
=
my 2 cents...

Aravind Sethuraman
Chief Software Architect
Tel= iris, Inc. =7C 55 Broadway, 14th =46loor, New York, NY 10006 =7C C += 1.917.355.0119 =7C O +1.212.490.1065 x1408 =7C =46 +1.212.269.2869 =7C= AIM aravindsraman

=20 <=21--

On Thursday, Ma= rch 24, 2011 at 9:44 PM, Roni Even wrote:

-->

On Thursday, March 24,= 2011 at 9:44 PM, Roni Even wrote:

Hi,
See my comments inline
Roni= Even

-----Original Message----= -
=46rom: clue-bounces=40ietf.org =5Bmailto:clue-bounces=40ietf.org=5D On Behalf Of
stephane.cazeaux=40= orange-ftgroup.com
Sent: Wednesday, March 23, 2011 7:11 PM
To: = clue=40ietf.org
Subject: =5B= clue=5D Comments on use cases

Hi,

After review of draft-rom= anow-clue-telepresence-use-cases-01.txt, below
are some comments about= use cases that we may want to consider, and
about some needed clarifi= cations.

1. Ad-hoc multi-stream telepresence room use case

= We may want to define a use case where a multi-stream telepresence roomis dynamically constituted of multiple mono-stream endpoints. The
te= lepresence room becomes an ad-hoc multi-stream telepresence room
becau= se we rely on endpoints that have been dynamically associated to
provi= de the multi-stream experience.
A good example is a multi-stream telep= resence room constituted of
several handheld telepresence devices (all= being mono-stream by
nature).

NOTE: The terms =22room=22 and =22= endpoint=22 are considered as interchangeable
in draft-romanow-clue-te= lepresence-requirements-01.txt. This point
changes this definition, si= nce a room could be constituted of multiple
endpoints.
I understand that this case involve multiple call set up and some = need for
co-relation between the multiple end points which do not have= a central
management entity. I am not sure that this use case is in t= he scope. I can
understand one endpoint making multiple calls but not = this case.



2. =221 to = n=22 multipoint conference use case
Basically, the sections 4.1 and 4.= 2 of draft-romanow-clue-telepresence-
use-cases-01.txt correspond to a= =221 to 1=22 meeting. The section 4.3
corresponds to a =22n=22 meetin= g. We may want to add the =221 to n=22 use case.
Examples of such use = case could be remote training, university course,
business meeting lik= e =22director's speech to employees=22, etc...
=46inally, this new use= is a generic version of the section 4.6, which is
a (very sophisticat= ed) sample of =221 to n=22 meeting.

We can consider the following = characteristics for this use case (not
exhaustive):
* Distinction b= etween main site (the main speaker) and remote sites
(the participants= )
* Multi-stream usage, more or less for the same principles as the on= es
describe in 4.6: remote sites always see the main site, remote site= s
and main site see a participant asking a question, etc.
* A remot= e site can ask for the word. The main site will see which site
request= s to take floor, and can choose to give the floor to a site. In
other = terms, this use case clarifies the need for a main site to
control lay= out and received streams on the remote sites, in a more
general manner= than the sample of the section 4.6.
* Conference topology discovery (= who is in the conference, and
configuration/capability of each site), = which could be displayed on the
main site to help the user to make aud= io/video selection (user choice).

I think that = is a subset of multipoint which is application driven. What is
known a= s =22lecture mode=22. The addition is the floor control that is part ofthe conference. The participant switching is application driven.


3. Collaboration

This draf= t seems to restrict the collaboration (or presentation) to the
usage o= f video as the only mean of sharing information. Why shall it be
restr= icted here=3F

In the context of telepresence where the target is (= among others) the
high quality of the experience, the solution of vide= o for data
collaboration is not the best, especially for technical doc= ument
sharing. Using video lowers quality, requires bandwidth and does= not
allow participants to take control of the document in turns.
<= br>We should consider the video as one mean. And take into account thenecessity of high quality experience to consider integrating and/or
d= efining other means=3F

Data collaboration is im= portant but can suggest a standard data
collaboration protocol.


4. Heterogeneous systems
<= br>The section 4.5 about heterogeneous systems is confusing. In particula= r
the sentence =22We are not here talking about legacy systems, but ra= ther
systems built to participate in such a conference, although they = are
single stream only=22, which seems to exclude support for legacy s= ystems=3F
It shall be clarified what =22heterogeneous systems=22 means= .

Can heterogeneous systems be defined as being constituted of:* Endpoints with different configurations: not the same number of
scr= eens, cameras, microphones, loudspeaker
* Endpoints with different cap= abilities: not the same configuration +
not the same available bandwid= th, screen size, endpoint size, access
network, CPU power, etc.
* L= egacy (aka. traditional) endpoints: non-standard endpoints (as
stated = in the charter) are excluded from this category.

This remark is al= so valid to draft-romanow-clue-telepresence-
requirements-01.txt which= talks of heterogeneous systems without
defining them clearly.

=

Regards,
Stephane Cazeaux


--
St=C3=A9phane Cazea= ux
Orange Labs
+33 2 31 75 95 40
stephane.cazeaux=40orange-ftgroup.com

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F
clue mailing list
clue=40= ietf.org
https://www.ietf.org/mailman/listinfo/clue
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
= clue mailing list
clue=40ietf.o= rg
http= s://www.ietf.org/mailman/listinfo/clue
 =20 =20 =20 =20
=20

--4d8bfa16_1e7ff521_a99-- From allyn@cisco.com Sat Mar 26 12:20:20 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFC003A695C for ; Sat, 26 Mar 2011 12:20:20 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jk5yu3ayyW62 for ; Sat, 26 Mar 2011 12:20:19 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 048563A695A for ; Sat, 26 Mar 2011 12:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4254; q=dns/txt; s=iport; t=1301167315; x=1302376915; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=SpuYtjKxE59bH88AaX7unSsudtSHncdVsAkyXt0O3Ac=; b=gyT7lARD9lnipLCyeYPfSCHOLMKOT7AzpCk3F+d4felJzL9SfC9wSNwk FPK578snkZ9zo0avAjQu2ooA+2qOhJ/vOhKHj9Lp4mG9Coliq4Y5FtU1J nxo1EpSwtlJQuSkH3Dm+XO2POjSadf77r/e1EJWKmF4ByrTRH7m0yS0IQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioBAHg8jk2rRDoJ/2dsb2JhbACYKY09d4hrnhKbVwKFZwSFOosW X-IronPort-AV: E=Sophos;i="4.63,249,1299456000"; d="scan'208";a="418777315" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 26 Mar 2011 19:21:54 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2QJLs15026158; Sat, 26 Mar 2011 19:21:54 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); Sat, 26 Mar 2011 12:21:54 -0700 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: Sat, 26 Mar 2011 12:21:50 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4D88B55B.80902@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control Thread-Index: Acvon2jjXyMbr/zDR52p3/ZzizyXLgDSFl0g References: <4D88B55B.80902@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" , "CLUE" X-OriginalArrivalTime: 26 Mar 2011 19:21:54.0112 (UTC) FILETIME=[10C10C00:01CBEBEB] Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 26 Mar 2011 19:20:20 -0000 Hi Magnus, A couple of brief comments inline below.=20 Also, since we are meeting this coming week, we could discuss further if = it seems like a good idea. Best regards, Allyn > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, March 22, 2011 7:43 AM > To: CLUE; Allyn Romanow (allyn) > Subject: draft-romanow-clue-telepresence-requirements-01: Additional > requirement for media, adaptation and media encoding control >=20 > Hi, >=20 > When reviewing draft-romanow-clue-telepresence-requirements-01 I > realized that it has no requirements on that the system supports > adaptation of the media streams. There are two aspects of this I see > that are related but have separate purposes and therefore warrants two > different requirements. >=20 > Media Adaptation Requirements: >=20 > ReqX: The Telepresence system needs to have congestion control of the > media streams. [AR] I agree this is important to consider, and within the scope of the = CLUE working group --however I think it is not within the scope of the = CLUE protocol of exchanging information for handling multiple streams, = which mostly boils down to layout, spatial relations, in addition to = stream characteristics - i. e., saying which streams are where when so = an adequate representation can be made at the receiver. =20 The CLUE group is chartered to consider additional issues related to = telepresence interoperability, and I feel this is where the congestion = control might be discussed. What do you think? >=20 > ReqX+1: Dynamic Control of sources' encoding of a media stream, in = such > aspects as video frame-rate, bit-rate upper limit, temporal spatial > quality trade-off, resolution, Full Intra Request, Picture Loss > Indicator, etc. [AR] Good catch - This was meant to be covered in the requirements, but = clearly was not done adequately. I had thought that Reqmt-1 covered = these types of stream characteristics, but it doesn't really now that I = see it again. So, yes I agree with you and will propose some text for including this = type of information. =20 As for the dynamic aspect, I do thing that is covered in Reqmt-2 Support = dynamic behavior of media streams, including:...changes in stream = characteristics...=20 What do you think? Thanks for your thoughtful comments- Allyn > Motivation: >=20 > Congestion Control is needed to enable Telepresence systems to work > also > over network paths that doesn't provide QoS guarantees or when QoS > guarantees fails. This problem is well studied for peer to peer > applications. With an RTP mixer in a multi-party conference session > then > this gets more complexed as one needs to consider both what can be > accomplished in the media source to the RTP mixer direction, and then > from the mixer to each of the other participants. This requires some > control of the media encoding in the sources by the RTP mixer to = ensure > that the media provided is as useful as possible. >=20 > The second requirement is based on the need to enable a conference > mixer > to maximize the medias usability for the participants. There are > several > aspects here: >=20 > - FIR for switching of video streams >=20 > - Bit-rate upper limit to adapt media stream to suit mixer to > participant direction. >=20 > - PLI to enable a participant with broken decoder state to get that > cleaned up. >=20 > - Frame-rate to adapt to receiver capabilities or change purpose of a > media stream. >=20 > - Temporal Spatial Trade-off if one wants to control video encoders to > prefer frame rate over spatial quality or the other way around. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Mar 29 00:05:44 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB903A6868 for ; Tue, 29 Mar 2011 00:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.53 X-Spam-Level: X-Spam-Status: No, score=-106.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddyIBKtjI70Y for ; Tue, 29 Mar 2011 00:05:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0CCEA3A67D0 for ; Tue, 29 Mar 2011 00:05:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-09-4d9185275ba1 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 86.E3.21265.725819D4; Tue, 29 Mar 2011 09:07:19 +0200 (CEST) Received: from [153.88.17.137] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 29 Mar 2011 09:07:18 +0200 Message-ID: <4D918525.9020002@ericsson.com> Date: Tue, 29 Mar 2011 09:07:17 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <4D88B55B.80902@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 07:05:44 -0000 Please see inline. Allyn Romanow (allyn) skrev 2011-03-26 20:21: > Hi Magnus, > > A couple of brief comments inline below. Also, since we are meeting > this coming week, we could discuss further if it seems like a good > idea. > > > Best regards, Allyn > >> -----Original Message----- From: Magnus Westerlund >> [mailto:magnus.westerlund@ericsson.com] Sent: Tuesday, March 22, >> 2011 7:43 AM To: CLUE; Allyn Romanow (allyn) Subject: >> draft-romanow-clue-telepresence-requirements-01: Additional >> requirement for media, adaptation and media encoding control >> >> Hi, >> >> When reviewing draft-romanow-clue-telepresence-requirements-01 I >> realized that it has no requirements on that the system supports >> adaptation of the media streams. There are two aspects of this I >> see that are related but have separate purposes and therefore >> warrants two different requirements. >> >> Media Adaptation Requirements: >> >> ReqX: The Telepresence system needs to have congestion control of >> the media streams. > > [AR] I agree this is important to consider, and within the scope of > the CLUE working group --however I think it is not within the scope > of the CLUE protocol of exchanging information for handling multiple > streams, which mostly boils down to layout, spatial relations, in > addition to stream characteristics - i. e., saying which streams are > where when so an adequate representation can be made at the receiver. > Well, CLUE does have a media plane, and we clearly have interoperability questions for it. I think congestion control is one. Clarifications on how to use RTP sessions seems to be another one. In that part as Clue develops usages and requirements AVT* can determine what issues that exist within this space and need clarification. > > The CLUE group is chartered to consider additional issues related to > telepresence interoperability, and I feel this is where the > congestion control might be discussed. What do you think? > My preferred model is that CLUE make it clear what requirements and what usages and topologies that are important and that this is thrown over the wall to the right AVT* group. >> >> ReqX+1: Dynamic Control of sources' encoding of a media stream, in >> such aspects as video frame-rate, bit-rate upper limit, temporal >> spatial quality trade-off, resolution, Full Intra Request, Picture >> Loss Indicator, etc. > > [AR] Good catch - This was meant to be covered in the requirements, > but clearly was not done adequately. I had thought that Reqmt-1 > covered these types of stream characteristics, but it doesn't really > now that I see it again. So, yes I agree with you and will propose > some text for including this type of information. > > As for the dynamic aspect, I do thing that is covered in Reqmt-2 > Support dynamic behavior of media streams, including:...changes in > stream characteristics... What do you think? > Adding that example is a great improvement. I wonder however, if some more expansive list on desired functionality would be good. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From allyn@cisco.com Tue Mar 29 05:00:04 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98D83A6A2D for ; Tue, 29 Mar 2011 05:00:04 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoE+BiaBoKD6 for ; Tue, 29 Mar 2011 05:00:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3D13F3A693E for ; Tue, 29 Mar 2011 05:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=4747; q=dns/txt; s=iport; t=1301400101; x=1302609701; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ba+0pDt5+1F7Qp24Mmot2tnJaAXXSip4Wqa1rVPOrlQ=; b=NcesOwWuzaSgBVaMLx87oro5ljG9jzydxv6jmPKZOFbGTLre0KWAJfIX /dLLAm2XnM+N6C/WWovNJZJGrHJnMB6LZEp3056Go8tBss0J5P8qPaf19 UQddUDZ1rTg9gjLguMMMqmRb6Kz9l4/2x0wNyAIZuArA2pDjVbAQFRg9Z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUAAB3JkU2rRDoG/2dsb2JhbACYD402d6hmnFAChWgEhTyLIA X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="672395764" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 29 Mar 2011 12:01:41 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2TC1fOs014486; Tue, 29 Mar 2011 12:01:41 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); Tue, 29 Mar 2011 05:01:41 -0700 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: Tue, 29 Mar 2011 05:00:57 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4D918525.9020002@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control Thread-Index: Acvt3/cLf0VDBjcsQMGxcVGdcXTddwAKJy2g References: <4D88B55B.80902@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> <4D918525.9020002@ericsson.com> From: "Allyn Romanow (allyn)" To: "Magnus Westerlund" X-OriginalArrivalTime: 29 Mar 2011 12:01:41.0309 (UTC) FILETIME=[10BC66D0:01CBEE09] Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 12:00:05 -0000 Hi Magnus, It sounds like we are in agreement on how to handle your point on = congestion control, and other AVT related issues. As for your second point about media stream description not being in the = requirements, how is this change to requirement 1? REQMT-1: Provide a means of describing the relationship of one stream = to another stream. This includes exchanging appropriate = information to enable: * layout to be accomplished, such as relevant spatial ordering = information=20 * Sender and/or receiver capabilities and preferences, such as = resolution, bandwidth, video frame rate > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, March 29, 2011 12:07 AM > To: Allyn Romanow (allyn) > Cc: CLUE > Subject: Re: draft-romanow-clue-telepresence-requirements-01: > Additional requirement for media, adaptation and media encoding = control >=20 > Please see inline. >=20 > Allyn Romanow (allyn) skrev 2011-03-26 20:21: > > Hi Magnus, > > > > A couple of brief comments inline below. Also, since we are meeting > > this coming week, we could discuss further if it seems like a good > > idea. > > > > > > Best regards, Allyn > > > >> -----Original Message----- From: Magnus Westerlund > >> [mailto:magnus.westerlund@ericsson.com] Sent: Tuesday, March 22, > >> 2011 7:43 AM To: CLUE; Allyn Romanow (allyn) Subject: > >> draft-romanow-clue-telepresence-requirements-01: Additional > >> requirement for media, adaptation and media encoding control > >> > >> Hi, > >> > >> When reviewing draft-romanow-clue-telepresence-requirements-01 I > >> realized that it has no requirements on that the system supports > >> adaptation of the media streams. There are two aspects of this I > >> see that are related but have separate purposes and therefore > >> warrants two different requirements. > >> > >> Media Adaptation Requirements: > >> > >> ReqX: The Telepresence system needs to have congestion control of > >> the media streams. > > > > [AR] I agree this is important to consider, and within the scope of > > the CLUE working group --however I think it is not within the scope > > of the CLUE protocol of exchanging information for handling multiple > > streams, which mostly boils down to layout, spatial relations, in > > addition to stream characteristics - i. e., saying which streams are > > where when so an adequate representation can be made at the = receiver. > > >=20 > Well, CLUE does have a media plane, and we clearly have > interoperability > questions for it. I think congestion control is one. Clarifications on > how to use RTP sessions seems to be another one. In that part as Clue > develops usages and requirements AVT* can determine what issues that > exist within this space and need clarification. >=20 > > > > The CLUE group is chartered to consider additional issues related to > > telepresence interoperability, and I feel this is where the > > congestion control might be discussed. What do you think? > > >=20 > My preferred model is that CLUE make it clear what requirements and > what > usages and topologies that are important and that this is thrown over > the wall to the right AVT* group. >=20 >=20 > >> > >> ReqX+1: Dynamic Control of sources' encoding of a media stream, in > >> such aspects as video frame-rate, bit-rate upper limit, temporal > >> spatial quality trade-off, resolution, Full Intra Request, Picture > >> Loss Indicator, etc. > > > > [AR] Good catch - This was meant to be covered in the requirements, > > but clearly was not done adequately. I had thought that Reqmt-1 > > covered these types of stream characteristics, but it doesn't really > > now that I see it again. So, yes I agree with you and will propose > > some text for including this type of information. > > > > As for the dynamic aspect, I do thing that is covered in Reqmt-2 > > Support dynamic behavior of media streams, including:...changes in > > stream characteristics... What do you think? > > >=20 > Adding that example is a great improvement. I wonder however, if some > more expansive list on desired functionality would be good. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From allyn@cisco.com Tue Mar 29 05:34:47 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0E53A681B for ; Tue, 29 Mar 2011 05:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFHrH1vXRj31 for ; Tue, 29 Mar 2011 05:34:45 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D3CA73A6781 for ; Tue, 29 Mar 2011 05:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=allyn@cisco.com; l=3395; q=dns/txt; s=iport; t=1301402184; x=1302611784; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fhcNedP995BNK7/8dWqV4E+8dIq+zwyc0oF6UZ0JVjk=; b=bq7PJ9C2sy4p8ixCIf0HvUYoQ49DYz8T/LflK0MEUE/aee0Kcy59UnGs gkcI0E+yx0chvhGX3KrzrwVpqVaFvTdz70g4PPv3NnZRmbA76FZ5IgtN2 D1V+EMDoU0IeM/L7AlbhYOmkGAw06cIuXWEqlvaHm1OGnOSbOqoTmK1VC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvMAAM7RkU2rRDoG/2dsb2JhbACYD409d4h5n1GcSIVqBIU8iyA X-IronPort-AV: E=Sophos;i="4.63,262,1299456000"; d="scan'208";a="284869869" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 12:36:24 +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 p2TCaOTc016264 for ; Tue, 29 Mar 2011 12:36:24 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); Tue, 29 Mar 2011 05:36:23 -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, 29 Mar 2011 05:36:14 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DF@xmb-sjc-221.amer.cisco.com> In-Reply-To: <4D8A4630.5090402@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-romanow-clue-telepresence-requirements-01.txt Thread-Index: Acvpjk7Ds0APaOEISIerX7yoMaWh4wEfEinA References: <4D8A4630.5090402@cisco.com> From: "Allyn Romanow (allyn)" To: "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 29 Mar 2011 12:36:23.0944 (UTC) FILETIME=[EA154880:01CBEE0D] Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 12:34:47 -0000 Hi Paul, These were very helpful comments.=20 I've cc'ed the mailing list. Thanks, Allyn > -----Original Message----- > From: Paul Kyzivat (pkyzivat) > Sent: Wednesday, March 23, 2011 12:13 PM > To: Allyn Romanow (allyn) > Subject: draft-romanow-clue-telepresence-requirements-01.txt >=20 > Allyn, >=20 > A few comments on the latest requirements draft: >=20 > Assumptions: >=20 > ASMP-1: Endpoints sending spatially related streams should make > sure > they are disjoint and arranged as announced. >=20 > Its an assumption that they *should* do this? I think it is probably an > assumption that they *do* this. (Same comment applies to several > assumptions.) >=20 AGREED I fixed them > ASMP-3: Layout can be done locally, remotely, or by a combination > of > the two. >=20 > Unclear. Is the assumption that all endpoints can do either? Or that > some endpoints may only be able to do one and not the other? OKAY, good point. Fixed >=20 > ASMP-6: Different systems do things differently. It is not the > intention of CLUE to dictate Telepresence architectural > and > implementation choices. Rather CLUE enables different > systems to interwork by exchanging information that > systems > can use to be interoperable. >=20 > But presumably it is an assumption that all systems relevant to clue do > conform to the assumptions. So there are limits to the differences, > right? Yes, agree.. do you want something to be said differently?? >=20 > Requirements: >=20 > REQMT-2: >=20 > This starts talking about things that happen in a "session" and end > talking about things that happen in a "conference". I think these are > meant as synonyms in this context. But if so it would be better to use > a > consistent term. If not, then the reason for the difference isn't > clear. In the draft I am looking at, -01, it talks about dynamic behavior of streams (at the beginning) as a result of changes in layout that may happen during a conference (at the end). So, they aren't synonyms. Do you want to check it again?=20 If you think it's still not clear, I'll add text to clarify - thanks >=20 > REQMT-3: Specify a mechanism for the receiver to tell the sender > (endpoint or middlebox)which streams it wants to > receive. > This includes specifying a way for the receiver to know > what the sender can send; and a way of designating > streams. >=20 > Offer/answer provides a way to do this at one level. But I'm quite sure > that isn't what you are talking about. Rather I presume you are talking > about "conceptual" or "specific" streams that could be provided if > desired. I'm not certain that is entirely clear here. >=20 If you want to suggest a change, I'll consider it. Otherwise, I probably think it's okay to use general language. > REQMT-9: CLUE must support different models of where layout > decisions are made - local and remote. ... >=20 > Does this imply a requirement to be able to negotiate which model is > used for each endpoint? >=20 Yes, I think so.. that's how I think of it (plus looks like a typo in that section.. two extra lines left over from another draft) > Thanks, > Paul From magnus.westerlund@ericsson.com Tue Mar 29 07:21:22 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4653A6A37 for ; Tue, 29 Mar 2011 07:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.531 X-Spam-Level: X-Spam-Status: No, score=-106.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nA5Zk-R14sd for ; Tue, 29 Mar 2011 07:21:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 62B3B3A68BC for ; Tue, 29 Mar 2011 07:21:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-09-4d91eb40c431 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A5.BB.21265.04BE19D4; Tue, 29 Mar 2011 16:22:56 +0200 (CEST) Received: from [153.88.18.37] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 29 Mar 2011 16:22:56 +0200 Message-ID: <4D91EB40.6020004@ericsson.com> Date: Tue, 29 Mar 2011 16:22:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Allyn Romanow (allyn)" References: <4D88B55B.80902@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> <4D918525.9020002@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DC@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DC@xmb-sjc-221.amer.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 14:21:22 -0000 Allyn Romanow (allyn) skrev 2011-03-29 14:00: > Hi Magnus, It sounds like we are in agreement on how to handle your > point on congestion control, and other AVT related issues. > > As for your second point about media stream description not being in the requirements, how is this change to requirement 1? > > REQMT-1: Provide a means of describing the relationship of one > stream to another stream. This includes exchanging appropriate information to enable: > * layout to be accomplished, such as relevant spatial ordering information > * Sender and/or receiver capabilities and preferences, such as resolution, bandwidth, video frame rate Not that it is not appropriate to have in the negotiation on capabilities or desired behavior from streams. However, I was actually desiring a dynamic control of these aspects of media streams during a session. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephen.botzko@gmail.com Tue Mar 29 07:32:18 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D48D3A68AA for ; Tue, 29 Mar 2011 07:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR792S4S4GiW for ; Tue, 29 Mar 2011 07:32:16 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 67D943A6882 for ; Tue, 29 Mar 2011 07:32:16 -0700 (PDT) Received: by vws12 with SMTP id 12so203001vws.31 for ; Tue, 29 Mar 2011 07:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kuAtVJR0swYLKc/fd64bcCb8clN+aVM0tm4RY9XXeP8=; b=rMoE9BUDRBu8951fXc7L36CQiX2AXbSTtU7Ryx0XyNF8MuuJk4zh1g51GAf1LakI9s 6cCBdYR0EmI/3yJaofG6hP8o6RerqyyyGCKUqtGLOp4g8ijV6/0qgu0OzT5QSahYZHDX wQttpZSGUNJf7WCo7q1LyCxCAvq5slPO83M24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N768PNr/SUelMIvpTpkocLC4mpkB/wFehglceFttvtEThE3QxE+yxBRiXL3szGWLmJ AaJYgYakCNn4N0/gBKENbCB9Y2NgxSNiiolYGaP10AYF1OL4gUQBshNOHSIPB2G0vBh6 OmwA02p8cLoZ/3qz03hHXHD1Dsp/b1T7lqX8g= MIME-Version: 1.0 Received: by 10.220.180.9 with SMTP id bs9mr1398313vcb.158.1301409234209; Tue, 29 Mar 2011 07:33:54 -0700 (PDT) Received: by 10.220.164.1 with HTTP; Tue, 29 Mar 2011 07:33:54 -0700 (PDT) In-Reply-To: <4D91EB40.6020004@ericsson.com> References: <4D88B55B.80902@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> <4D918525.9020002@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DC@xmb-sjc-221.amer.cisco.com> <4D91EB40.6020004@ericsson.com> Date: Tue, 29 Mar 2011 16:33:54 +0200 Message-ID: From: Stephen Botzko To: Magnus Westerlund Content-Type: multipart/alternative; boundary=90e6ba53b1d01ccd8f049f9ff3a0 Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 14:32:18 -0000 --90e6ba53b1d01ccd8f049f9ff3a0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus I agree that we will want some ability to control some aspects of the media dynamically mid-call. Though I think is also a need to give the encoder freedom to choose the bes= t possible mode. For instance video framerate is often slowed down during fast motion in order to maintain the best bitrate. I am not sure that receiver-driven controls over all parameters is needed. Similarly, providing feedback on the desired receive video resolution for a particular is valuable. But if the same stream is going to multiple destinations, the encoder should be able to ignore this feedback. Stephen Botzko On Tue, Mar 29, 2011 at 4:22 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Allyn Romanow (allyn) skrev 2011-03-29 14:00: > > Hi Magnus, It sounds like we are in agreement on how to handle your > > point on congestion control, and other AVT related issues. > > > > As for your second point about media stream description not being in > the requirements, how is this change to requirement 1? > > > > REQMT-1: Provide a means of describing the relationship of one > > stream to another stream. This includes exchanging appropriate > information to > enable: > > * layout to be accomplished, such as relevant spatial ordering > information > > * Sender and/or receiver capabilities and preferences, such as > resolution, > bandwidth, video frame rate > > Not that it is not appropriate to have in the negotiation on > capabilities or desired behavior from streams. > > However, I was actually desiring a dynamic control of these aspects of > media streams during a session. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --90e6ba53b1d01ccd8f049f9ff3a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Magnus

I agree that we will want some ability to control some asp= ects of the media dynamically mid-call.

Though I think is also a nee= d to give the encoder freedom to choose the best possible mode.=A0 For inst= ance video framerate is often slowed down during fast motion in order to ma= intain the best bitrate.=A0 I am not sure that receiver-driven controls ove= r all parameters is needed.=A0

Similarly, providing feedback on the desired receive video resolution f= or a particular is valuable.=A0 But if the same stream is going to multiple= destinations, the encoder should be able to ignore this feedback.

Stephen Botzko

On Tue, Mar 29, 2011 at 4:= 22 PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:<= br>
Allyn Romanow (al= lyn) skrev 2011-03-29 14:00:
> Hi Magnus, It sounds like we are in agreement on how= to handle your
> point on congestion control, and other AVT related issues.
>
> As for your second point about media stream description not being in the requirements, how is this change to requirement 1?
>
> REQMT-1: Provide a means of describing the relationship of one
> stream to another stream. This includes exchanging appropriate informa= tion to
enable:
> * layout to be accomplished, such as relevant spatial ordering informa= tion
> * Sender and/or receiver capabilities and preferences, such as resolut= ion,
=A0 =A0bandwidth, video frame rate

Not that it is not appropriate to have in the negotiation on
capabilities or desired behavior from streams.

However, I was actually desiring a dynamic control of these aspects of
media streams during a session.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--90e6ba53b1d01ccd8f049f9ff3a0-- From magnus.westerlund@ericsson.com Tue Mar 29 07:42:29 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E0A3A682D for ; Tue, 29 Mar 2011 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNG+N7YZ6v1h for ; Tue, 29 Mar 2011 07:42:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 52EC23A67D3 for ; Tue, 29 Mar 2011 07:42:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7bbbae000005311-c9-4d91f035a5d9 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 14.CE.21265.530F19D4; Tue, 29 Mar 2011 16:44:05 +0200 (CEST) Received: from [153.88.18.37] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 29 Mar 2011 16:44:04 +0200 Message-ID: <4D91F034.5000103@ericsson.com> Date: Tue, 29 Mar 2011 16:44:04 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Stephen Botzko References: <4D88B55B.80902@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> <4D918525.9020002@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DC@xmb-sjc-221.amer.cisco.com> <4D91EB40.6020004@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 14:42:29 -0000 Stephen Botzko skrev 2011-03-29 16:33: > Hi Magnus > > I agree that we will want some ability to control some aspects of the > media dynamically mid-call. > > Though I think is also a need to give the encoder freedom to choose the > best possible mode. For instance video framerate is often slowed down > during fast motion in order to maintain the best bitrate. I am not sure > that receiver-driven controls over all parameters is needed. > > Similarly, providing feedback on the desired receive video resolution > for a particular is valuable. But if the same stream is going to > multiple destinations, the encoder should be able to ignore this feedback. > Not disagreeing with these comments. This comes in several flavors. One is expressing preferences for what is received. There is another case when the mixer will desire to put hard restrictions on the source encoder to make it suitable for distribution to more receivers. What is suitable for a particular knob I think depends on which knob it is and what control its have. So in centralized mixer topologies there can be a clear difference in semantics between the client -> mixer direction to the mixer->client one. For point to point both semantics can be useful depending on what one tries to achieve. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From stephen.botzko@gmail.com Tue Mar 29 07:48:45 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD56B3A682B for ; Tue, 29 Mar 2011 07:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKUnrfyPIdEp for ; Tue, 29 Mar 2011 07:48:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 804AE3A67AB for ; Tue, 29 Mar 2011 07:48:44 -0700 (PDT) Received: by vxg33 with SMTP id 33so223516vxg.31 for ; Tue, 29 Mar 2011 07:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3pAsjhTXMuUxSzP1I+SdtNQ8pM6eAmgwoHTejXGyRn4=; b=brqjdLvpRqDmz6XK8mYTNqeoGK3HyhMtfmcVSI6vD4PGbOId/5mm74SlaJ2p3+J71Z xXjJ72Qhtus5WC3E41oQA/WhRBS4xzyVN4urHLFQlTs4oFSnaIWyHKjBWR6GPnnCxqt1 AC20RtwIPjh+yfvOKECnob1jDuUqlfZqV9ASw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SmAeCj5JiGOWqBjyq4j+lty+OeThRND4xaY/mmxFTqC/02UnN+03bJJ3MtK/dHIRsT QlEs+xu0Alne2fP9qB2WhQnF+JsD+hJbwquGWMprHoyZpSrgCUGwVHJEfT2ngZVd7PaA m+v+RHyCK+bGRc5nJiKpsEofn7XEIPl+0KGs4= MIME-Version: 1.0 Received: by 10.220.128.205 with SMTP id l13mr1397642vcs.193.1301410222340; Tue, 29 Mar 2011 07:50:22 -0700 (PDT) Received: by 10.220.164.1 with HTTP; Tue, 29 Mar 2011 07:50:22 -0700 (PDT) In-Reply-To: <4D91F034.5000103@ericsson.com> References: <4D88B55B.80902@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> <4D918525.9020002@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DC@xmb-sjc-221.amer.cisco.com> <4D91EB40.6020004@ericsson.com> <4D91F034.5000103@ericsson.com> Date: Tue, 29 Mar 2011 16:50:22 +0200 Message-ID: From: Stephen Botzko To: Magnus Westerlund Content-Type: multipart/alternative; boundary=e0cb4e887849027a3a049fa02e4f Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 29 Mar 2011 14:48:45 -0000 --e0cb4e887849027a3a049fa02e4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So perhaps a good way to proceed is for people to propose specific controls (knobs), and describe their value in the various topologies. Stephen Botzko On Tue, Mar 29, 2011 at 4:44 PM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Stephen Botzko skrev 2011-03-29 16:33: > > Hi Magnus > > > > I agree that we will want some ability to control some aspects of the > > media dynamically mid-call. > > > > Though I think is also a need to give the encoder freedom to choose the > > best possible mode. For instance video framerate is often slowed down > > during fast motion in order to maintain the best bitrate. I am not sur= e > > that receiver-driven controls over all parameters is needed. > > > > Similarly, providing feedback on the desired receive video resolution > > for a particular is valuable. But if the same stream is going to > > multiple destinations, the encoder should be able to ignore this > feedback. > > > > Not disagreeing with these comments. > > This comes in several flavors. One is expressing preferences for what is > received. There is another case when the mixer will desire to put hard > restrictions on the source encoder to make it suitable for distribution > to more receivers. What is suitable for a particular knob I think > depends on which knob it is and what control its have. > > So in centralized mixer topologies there can be a clear difference in > semantics between the client -> mixer direction to the mixer->client > one. For point to point both semantics can be useful depending on what > one tries to achieve. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > --e0cb4e887849027a3a049fa02e4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So perhaps a good way to proceed is for people to propose specific controls= (knobs), and describe their value in the various topologies.=A0

St= ephen Botzko

On Tue, Mar 29, 2011 at 4:44= PM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Stephen Botzko sk= rev 2011-03-29 16:33:
> Hi Magnus
>
> I agree that we will want some ability to control some aspects of the<= br> > media dynamically mid-call.
>
> Though I think is also a need to give the encoder freedom to choose th= e
> best possible mode. =A0For instance video framerate is often slowed do= wn
> during fast motion in order to maintain the best bitrate. =A0I am not = sure
> that receiver-driven controls over all parameters is needed.
>
> Similarly, providing feedback on the desired receive video resolution<= br> > for a particular is valuable. =A0But if the same stream is going to > multiple destinations, the encoder should be able to ignore this feedb= ack.
>

Not disagreeing with these comments.

This comes in several flavors. One is expressing preferences for what is received. There is another case when the mixer will desire to put hard
restrictions on the source encoder to make it suitable for distribution
to more receivers. What is suitable for a particular knob I think
depends on which knob it is and what control its have.

So in centralized mixer topologies there can be a clear difference in
semantics between the client -> mixer direction to the mixer->client<= br> one. For point to point both semantics can be useful depending on what
one tries to achieve.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--e0cb4e887849027a3a049fa02e4f-- From spromano@unina.it Wed Mar 30 09:16:46 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C963A6B8B for ; Wed, 30 Mar 2011 09:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.502 X-Spam-Level: X-Spam-Status: No, score=-100.502 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYaDelOmXV3H for ; Wed, 30 Mar 2011 09:16:45 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by core3.amsl.com (Postfix) with ESMTP id E8EDB3A6A48 for ; Wed, 30 Mar 2011 09:16:44 -0700 (PDT) Received: from [130.129.23.172] (dhcp-17ac.meeting.ietf.org [130.129.23.172]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id p2UGIMad006446 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 30 Mar 2011 18:18:23 +0200 Message-ID: <4D9357C4.2090009@unina.it> Date: Wed, 30 Mar 2011 18:18:12 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: clue@ietf.org Content-Type: multipart/alternative; boundary="------------020909030804080109080407" Subject: [clue] Fwd: CLUE recording available X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 30 Mar 2011 16:16:46 -0000 This is a multi-part message in MIME format. --------------020909030804080109080407 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit ...for a mere error, I sent this mail to the DISPATCH mailing list. Sorry about that, Simon -------- Messaggio originale -------- Oggetto: CLUE recording available Data: Wed, 30 Mar 2011 18:09:19 +0200 Mittente: Simon Pietro Romano A: DISPATCH Dear all, the full recording (synchronized video, audio, slides and jabber room) of today's CLUE session is available at the following URL: http://ietf.conf.meetecho.com In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, Simon -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------020909030804080109080407 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit ...for a mere error, I sent this mail to the DISPATCH mailing list.

Sorry about that,

Simon

-------- Messaggio originale --------
Oggetto: CLUE recording available
Data: Wed, 30 Mar 2011 18:09:19 +0200
Mittente: Simon Pietro Romano <spromano@unina.it>
A: DISPATCH <dispatch@ietf.org> 


Dear all,

the full recording (synchronized video, audio, slides and jabber room) 
of today's CLUE session is available at the following URL:

http://ietf.conf.meetecho.com

In case of problems with the playout, just drop an e-mail to 
ietf-support@meetecho.com.

Cheers,

Simon

-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------020909030804080109080407-- From christer.holmberg@ericsson.com Thu Mar 31 02:07:05 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D48528C1E1 for ; Thu, 31 Mar 2011 02:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTWY9qg2GBRa for ; Thu, 31 Mar 2011 02:07:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BB02D28C1E0 for ; Thu, 31 Mar 2011 02:07:01 -0700 (PDT) X-AuditID: c1b4fb39-b7c6dae0000023f2-33-4d944498e08a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0D.88.09202.894449D4; Thu, 31 Mar 2011 11:08:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 31 Mar 2011 11:08:40 +0200 From: Christer Holmberg To: "clue@ietf.org" Date: Thu, 31 Mar 2011 11:08:38 +0200 Thread-Topic: IETF#80: Notes Thread-Index: Acvvgzjszeqwu3DnQ7m59RcxJq3XRw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194913F9D0@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A0585194913F9D0ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [clue] IETF#80: Notes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 09:07:05 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194913F9D0ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my notes from the CLUE WG session. Regards, Christer ------------- USE-CASES: Presenter: Peter Musgrave Draft: draft-romanow-clue-telepresence-use-cases-01.txt Abstract: - Peter presented the types of use-cases currently described in the draft. Discussions: - There was a discussion about whether floor control was within the scope o= f CLUE. It was indicated that there are other working groups working on gen= eral mechanism, not only applicable to CLUE, that might be usable. - There was a discussion whether the use-cases should be structured in a di= fferent way, e.g. centralized vs peer-to-peer. - There was a discussion that the current use-cases might need to be split = into additional use-cases. Action points: - Need to more clearly define the difference between a heteregenous use-cas= e a assymetric use-cases, pointing out that an heteregenous client migth no= t understand the new features, protocol elements etc defined in CLUE. - Additional use-cases will be provided, as the current ones seemed to be s= howing certain deployed scenarios. - The terminology in the document needs to be clear and well defined, so th= at everyone has the same understanding. Poll: - Willing to review and contribute to the document: 20+ individuals Hum: - Adopt the use-case document: Room concensus, no objection RQUIREMENTS Presenter: Allyn Romanow Draft: draft-romanow-clue-telepresence-requirements-01.txt Abstract: - Allyn presented the assumptions and requirements currently presented in t= he draft. Discussions (assumptions): - For the assumptions, it was indicated that some of them probably belong t= o the WG charter, or to the problem statement description of the WG. Some o= f the assumptions will be removed, and the text associated with those assum= ptions might be moved elsewhere. - It was commented that entities have control of what is sent, but that we = can not make assumptions that receivers will render streams in a particular= way. Rather, endpoints need to get enough information about the streams in= order to be able to render them in a good way. Discussions (requirements): - There was a general comment that every requirement should be written in a= consistant way, indicating what the solution/system needs to support. - REQS-1: The requirement shall be split into separate requirements for str= eam relationship and sender/receiver capabilitites - REQS-1: The note shall either be removed, or moved into a separate requir= ement - REQs-3: The requirement shall be split into separate requirements - REQS-4: Clarify what type of synchronization is meant. Time synchronizati= on. - REQS-5: The "arbitrary" terminology is unclear, and that the WG should no= t try to to come up with maximum number of capture devices etc. - REQS-6: Needs to clarify exactly what is negotiatied/re-negotiated - REQs-7: Only first part of requirement is needed. The rest should be cove= red in the definitions section. --_000_7F2072F1E0DE894DA4B517B93C6A0585194913F9D0ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Below are my notes from the CLUE WG session.
 
Regards,
 
Christer
 
-------------
 
 
USE-CASES:
 
Presenter: Peter Musgrave
Draft: draft-romanow-clue-telepresence-use-cases-01.t= xt
 
 
Abstract:
 
- Peter presented the types of use-cases currently de= scribed in the draft.
 
 
Discussions:
 
- There was a discussion about whether floor control = was within the scope of CLUE. It was indicated that there are other working= groups working on general mechanism, not only applicable to CLUE, that mig= ht be usable.
 
- There was a discussion whether the use-cases should= be structured in a different way, e.g. centralized vs peer-to-peer.=
 
- There was a discussion that the current use-cases m= ight need to be split into additional use-cases.
 
 
 
Action points:
 
- Need to more clearly define the difference between = a heteregenous use-case a assymetric use-cases, pointing out that an hetere= genous client migth not understand the new features, protocol elements etc = defined in CLUE.
 
- Additional use-cases will be provided, as the curre= nt ones seemed to be showing certain deployed scenarios.
 
- The terminology in the document needs to be clear a= nd well defined, so that everyone has the same understanding.
 
 
Poll:
 
- Willing to review and contribute to the document: 2= 0+ individuals
 
 
Hum:
 
- Adopt the use-case document: Room concensus, no obj= ection
 
 
RQUIREMENTS
 
Presenter: Allyn Romanow
Draft: draft-romanow-clue-telepresence-requirements-0= 1.txt
 
Abstract:
 
- Allyn presented the assumptions and requirements cu= rrently presented in the draft.
 
 
Discussions (assumptions):
 
- For the assumptions, it was indicated that some of = them probably belong to the WG charter, or to the problem statement descrip= tion of the WG. Some of the assumptions will be removed, and the text assoc= iated with those assumptions might be moved elsewhere.
 
- It was commented that entities have control of what= is sent, but that we can not make assumptions that receivers will render s= treams in a particular way. Rather, endpoints need to get enough informatio= n about the streams in order to be able to render them in a good way.
 
 
Discussions (requirements):
 
- There was a general comment that every requirement = should be written in a consistant way, indicating what the solution/system = needs to support.
- REQS-1: The requirement shall be split into separat= e requirements for stream relationship and sender/receiver capabilitites
- REQS-1: The note shall either be removed, or moved = into a separate requirement
- REQs-3: The requirement shall be split into separat= e requirements
- REQS-4: Clarify what type of synchronization is mea= nt. Time synchronization.
- REQS-5: The "arbitrary" terminology is un= clear, and that the WG should not try to to come up with maximum number of = capture devices etc.
- REQS-6: Needs to clarify exactly what is negotiatie= d/re-negotiated
- REQs-7: Only first part of requirement is needed. T= he rest should be covered in the definitions section.
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194913F9D0ESESSCMS0356e_-- From espeberg@cisco.com Thu Mar 31 02:33:03 2011 Return-Path: X-Original-To: clue@core3.amsl.com Delivered-To: clue@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C579528C282 for ; Thu, 31 Mar 2011 02:33:03 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LnbQFkjjajD for ; Thu, 31 Mar 2011 02:33:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 56FC928C270 for ; Thu, 31 Mar 2011 02:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=espeberg@cisco.com; l=3284; q=dns/txt; s=iport; t=1301564068; x=1302773668; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=VK1ACkf+x7U1FabCPIDIOfaQ0zYniYczxdqnwSKsp/I=; b=St3LmrlDwTbDhtwIJBmgqTdfCqK10mqZ4W5jVxAoOyu/qd30972vwV0X +u52UDSvh6P5Jd7jX30b1/TXrTgxpza3mrxL7vmcZZXXJc6L2wlv70+qS mhEMeeW+ew8e0yCELdnTblQ7UUYPkyq2h7FqzCMeugyivXjjrhomqrl1B g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtoDAGtKlE2Q/khLgWdsb2JhbAClTxQBARYmJaI/nBAChWkEkGw X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="81610279" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2011 09:34:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2V9YM3i031590; Thu, 31 Mar 2011 09:34:22 GMT Received: from xmb-ams-214.cisco.com ([144.254.75.25]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 11:34:22 +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, 31 Mar 2011 11:34:21 +0200 Message-ID: <92DF9533227FC14F946C7321074B8C9E51A71B@XMB-AMS-214.cisco.com> In-Reply-To: <4D91F034.5000103@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control Thread-Index: AcvuH8j5rzNsZ17kS9KHFv+OdCSMAgBZWRMQ References: <4D88B55B.80902@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F2844F@xmb-sjc-221.amer.cisco.com> <4D918525.9020002@ericsson.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC03F289DC@xmb-sjc-221.amer.cisco.com> <4D91EB40.6020004@ericsson.com> <4D91F034.5000103@ericsson.com> From: "Espen Berger (espeberg)" To: "Magnus Westerlund" , "Stephen Botzko" X-OriginalArrivalTime: 31 Mar 2011 09:34:22.0889 (UTC) FILETIME=[D1740990:01CBEF86] Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: Additional requirement for media, adaptation and media encoding control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.9 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, 31 Mar 2011 09:33:04 -0000 I think it's a useful feature to separate maximum capabilities with = preferred capabilities. Examples of max capabilities and preferred = capabilities.=20 Max-caps=20 * Max-mbps=20 * Bit rate=20 Preferences * Resolution =20 * fps (Frames pr. second) A receiver can then request a stream with a maximum bit rate of 2 mb/s = (absolute maximum) and hint that it prefer 60 fps. It should give the = encoder enough information be configured with high frame rate and lower = resolution. The bit rate of 720p60 is comparable to 1080p30, hence an = encoder need some help to choose between the two options. The video = decoder should be able to decode any stream that is inside the max-mbps = and bit rate limits (I think that is a H.264 spec requirement). =20 In a point to point call the receiving endpoint can select, in a = multipoint call the multipoint server can aggregate request from the = multiple receivers, or in multi cast scenarios the sender can do the = aggregation.=20 -Espen=20 -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Magnus Westerlund Sent: 29. mars 2011 16:44 To: Stephen Botzko Cc: CLUE Subject: Re: [clue] draft-romanow-clue-telepresence-requirements-01: = Additional requirement for media, adaptation and media encoding control Stephen Botzko skrev 2011-03-29 16:33: > Hi Magnus >=20 > I agree that we will want some ability to control some aspects of the > media dynamically mid-call. >=20 > Though I think is also a need to give the encoder freedom to choose = the > best possible mode. For instance video framerate is often slowed down > during fast motion in order to maintain the best bitrate. I am not = sure > that receiver-driven controls over all parameters is needed.=20 >=20 > Similarly, providing feedback on the desired receive video resolution > for a particular is valuable. But if the same stream is going to > multiple destinations, the encoder should be able to ignore this = feedback. >=20 Not disagreeing with these comments. This comes in several flavors. One is expressing preferences for what is received. There is another case when the mixer will desire to put hard restrictions on the source encoder to make it suitable for distribution to more receivers. What is suitable for a particular knob I think depends on which knob it is and what control its have. So in centralized mixer topologies there can be a clear difference in semantics between the client -> mixer direction to the mixer->client one. For point to point both semantics can be useful depending on what one tries to achieve. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue