From pkyzivat@alum.mit.edu Mon Sep 2 12:50:56 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97D821F9E89 for ; Mon, 2 Sep 2013 12:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbOPQ0colbQN for ; Mon, 2 Sep 2013 12:50:52 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 09CDC21F9D7D for ; Mon, 2 Sep 2013 12:50:51 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id LEoa1m0051swQuc55KqrRo; Mon, 02 Sep 2013 19:50:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id LKqr1m00E3ZTu2S3bKqro9; Mon, 02 Sep 2013 19:50:51 +0000 Message-ID: <5224EC1A.1020603@alum.mit.edu> Date: Mon, 02 Sep 2013 15:50:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> In-Reply-To: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378151451; bh=BpKBhynRcDKUjFqEojb9YMRD5Qyshd79G+sDJrW//Qw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DS/O3uQjbowBGVjWXMiZaYndnoA8PabC73sYMfUC5tWHnfkIS7XfyvhCS+phAhIYc +ILZA7LlEdxfNl3JJn3x0sp4fNahaQHV1fbN0lRa+7XytmgIU8wwcXCh7KEJ6nSOZX 2J/vvVyZsoFATgmMjbuPE7oR19hrZmFDflUplQWsOFcOVIf+D+z1kMlrXdvpRKBSPG eOOoLuTqB99GRpblcSdb6UiY2C9eLc7vwuVMZGdocqsx9fhlw/+U+d0WkQBuhilyU8 uQL8yYT2hd7XnahkXhvnMlYF3g45ACOtNTEpOLD7h71oHKzNN75mRsxItLXRTMFJW0 G5hKtLUSK9T/Q== Subject: [clue] WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2013 19:50:57 -0000 With this message I'm announcing the start of WGLC for draft-ietf-clue-telepresence-requirements-05 This WGLC will last for roughly two weeks, ending at midnight GMT on Sunday September 15. It is important to have decisive results from a WGLC. (Silence doesn't do it.) So please, take a last careful look at these requirements and comment. If you like these as they are, please say so. Thanks, Paul (as co-chair) On 8/30/13 6:39 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : Requirements for Telepresence Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : draft-ietf-clue-telepresence-requirements-05.txt > Pages : 13 > Date : 2013-08-30 > > Abstract: > This memo discusses the requirements for a specification that enables > telepresence interoperability, by describing the relationship between > multiple RTP streams. In addition, the problem statement and > definitions are also covered herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Tue Sep 3 08:07:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2A121E8130 for ; Tue, 3 Sep 2013 08:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tS5OThJorw0S for ; Tue, 3 Sep 2013 08:07:45 -0700 (PDT) Received: from mail-qe0-x22e.google.com (mail-qe0-x22e.google.com [IPv6:2607:f8b0:400d:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C6DCE11E81E4 for ; Tue, 3 Sep 2013 08:07:02 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id x7so1687093qeu.33 for ; Tue, 03 Sep 2013 08:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=uEoShUQtT9i1g5xZq6wmfJYqHDZhYGC6gwZOPTA//NA=; b=0xWs9CyGcQTITB7ibXk478dlDmVmELrmxn88aSk27wGO/h3NHT7WgpCF3dNLfiWild ibm303rSYQp+KwocgmQPbrH2OMBSOk/HkR44O5ItnekmpybILijIjCgbNzp46c+mNvYq dluWkcUYOfW+Ho2b6mQDZdYZoJvKa277wCueVLfo2btlDBDaC4wpzZKPbOP8z0Y7h+Lj ToHs1/GXIjmSTVpn5AG14QISphaXpZ1NMkRuOPGmvAoEBA0/5kiMQtxUdJJ8aYwyZFyd HqdiQK/00VG7DDo7AS8Yt2FbCDzzkE2qU2F01Dlnz+iJWNdfbZYmVxwEH2z823NW5SDy PtYg== MIME-Version: 1.0 X-Received: by 10.49.35.106 with SMTP id g10mr24776861qej.35.1378220818301; Tue, 03 Sep 2013 08:06:58 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 3 Sep 2013 08:06:58 -0700 (PDT) Date: Tue, 3 Sep 2013 10:06:58 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b6766f84c0b5004e57c0a15 Cc: Roni Even Subject: [clue] Preparing PROTO Write-up for Use case document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:07:51 -0000 --047d7b6766f84c0b5004e57c0a15 Content-Type: text/plain; charset=ISO-8859-1 Hi all, In the process of re-reviewing the use cases document in preparation of the PROTO write-up, I came across the following nits and a couple minor issues that I would like to discuss with the WG. Thanks, Mary. Minor issues: ------------------- - Section 2, first two paragraphs after numbered list. I struggled a little bit with this text (which is more of a problem statement) in a section that's providing an overview of scenarios. I would suggest to move the first of those two paragraphs into section 1 and delete that 2nd paragraph (in section 2) as I think what's important is the current last sentence of the 2nd paragraph in section 1. Thus, I'm suggesting changing the 2nd paragraph in section 1 as follows: OLD: Although telepresence systems are based on open standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor's protocol to another. A standard way of describing the multiple streams constituting the media flows and the fundamental aspects of their behavior, would allow telepresence systems to interwork. NEW: Although telepresence systems are based on open standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor's protocol to another. The basic features that give telepresence its distinctive characteristics are implemented in disparate ways in different systems. Currently Telepresence systems from diverse vendors interoperate to some extent, but this is not supported in a standards based fashion. Interworking requires that translation and transcoding devices be included in the architecture. Such devices increase latency, reducing the quality of interpersonal interaction. Use of these devices is often not automatic; it frequently requires substantial manual configuration and a detailed understanding of the nature of underlying audio and video streams. This state of affairs is not acceptable for the continued growth of telepresence - telepresence systems should have the same ease of interoperability as do telephones. Thus, a standard way of describing the multiple streams constituting the media flows and the fundamental aspects of their behavior, would allow telepresence systems to interwork. - Section 3.4, 5th paragraph : This seems misplaced as there isn't anywhere else in the document where we talk about protocols (this is something which would really be more appropriately discussed in the solution documents). I would suggest to delete this paragraph. Nits: ------- - Section 1, 3rd paragraph, 1st sentence: "draft"->"document", "requirements will be derived" -> "requirements are derived" - Section 1, last paragraph: Need to add two spaces after "This document structure is as follows:" - Section 2, "users we will call participant cameras" -> "users are referred to as participant cameras" (consistent with wording a couple sentences down) - Section 3, first sentence. Adding spacing after the sentence. - Section 3.7, first paragraph, 1st sentence. Adding spacing after the sentence. - Section 3.9, first paragraph, last sentence. This is awkwardly worded. I suggest changing: "assist the process of the surgery" to simply "assist in the surgery" or "assist in the surgical process" - Section 4. 1st para. "draft" -> "document" --047d7b6766f84c0b5004e57c0a15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

In the process of re-reviewing = the use cases document in preparation of the PROTO write-up, I came across = the following nits and a couple minor issues that I would like to discuss w= ith the WG.=A0

Thanks,
Mary.

Minor = issues:
-------------------

- Section 2,= first two paragraphs after numbered list. =A0I struggled a little bit with= this text (which is more of a problem statement) in a section that's p= roviding an overview of scenarios. I would suggest to move the first of tho= se two paragraphs into section 1 and delete that 2nd paragraph (in section = 2) =A0as I think what's important is the current last sentence of the 2= nd paragraph in section 1. =A0Thus, I'm suggesting changing the 2nd par= agraph in section 1 as follows:
OLD:
Although t= elepresence systems are based on open standards such as RTP[RFC3550], SIP [RFC3261], H.264, and th= e H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each other without operator assistance and exp= ensive additional equipment which translates from one vendor's protocol to another. A standar= d way of describing the= multiple streams constituting the media flows and the fundamental aspects of their behavior, wo= uld allow telepresence = systems to interwork.

NEW:=A0
Although telepresence systems are based on open standards such as R= TP[RFC3550], SIP [RFC32= 61], H.264, and the H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each = other without operator = assistance and expensive additional equipment which translates from one vendor's protocol to a= nother.=A0
The basic features that g= ive telepresence its distinctive c= haracteristics are implemented in disparate ways in different systems. Currently Telepresence systems from d= iverse vendors interoperate to som= e extent, but this is not supported in a standards based fashion. Interworking requires that translation and<= /span> transcoding devices be included in= the architecture. Such devices i= ncrease latency, reducing the quality of interpersonal interaction.<= span class=3D"Apple-style-span" style=3D"color:rgb(0,0,0);font-size:medium"= > Use of these devices is often not automat= ic; it frequently requires substan= tial manual configuration and a detailed understanding of the nature of underlying audio and video streams. = This state of affairs is not accep= table for the continued growth of telepresence - telepresence systems should have the same ease of interopera= bility as <= /span>do telephones. <= span class=3D"Apple-style-span" style=3D"font-family:monospace;white-space:= pre-wrap;color:rgb(0,0,0);font-size:medium">Thus, a standard way of describing the multiple streams constituting the medi= a flows and the fundame= ntal aspects of their behavior, would allow telepresence systems to interwork.

- Section 3.4, 5th paragraph : =A0This seems mispl= aced as there isn't anywhere else in the document where we talk about p= rotocols (this is something which would really be more appropriately discus= sed in the solution documents). =A0I would suggest to delete this paragraph= . =A0

Nits:
-------
- Section 1, 3rd para= graph, 1st sentence: "draft"->"document", "requ= irements will be derived" -> "requirements are derived"
- Section 1, last paragraph: Need to add two spaces after "This d= ocument structure is as follows:" =A0=A0
- Section 2, "= users we will call participant cameras" -> "users are referred= to as participant cameras" =A0(consistent with wording a couple sente= nces down)=A0
- Section 3, first sentence. =A0Adding spacing after the sentence.=A0<= /div>
- Section 3.7, first paragraph, 1st sentence. =A0Adding spacing a= fter the sentence.
- Section 3.9, first paragraph, last sentence.= =A0This is awkwardly worded. I suggest changing: "assist the process = of the surgery" to simply "assist in the surgery" or "a= ssist in the surgical process"=A0
- Section 4. =A01st para. "draft" -> "document"=
--047d7b6766f84c0b5004e57c0a15-- From trac+clue@trac.tools.ietf.org Tue Sep 3 08:20:17 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3947311E8211 for ; Tue, 3 Sep 2013 08:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkuzukY9xTtI for ; Tue, 3 Sep 2013 08:20:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0778A11E820B for ; Tue, 3 Sep 2013 08:20:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:58568 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsOq-0005su-Ho; Tue, 03 Sep 2013 17:20:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:20:12 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/34#comment:1 Message-ID: <083.e2ae4e1db7c7b395b6fe5b1b6325d214@trac.tools.ietf.org> References: <068.af8e067d89686381df3799eef29348b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <068.af8e067d89686381df3799eef29348b5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #34: Update Framework Examples X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:20:17 -0000 #34: Update Framework Examples Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This ticket has been resolved in the -11 version and agreed to be closed at IETF-87. -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: task | Status: closed Priority: minor | Milestone: Component: framework | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:23:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF7B21E8120 for ; Tue, 3 Sep 2013 08:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsGRiOoRgN33 for ; Tue, 3 Sep 2013 08:23:09 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EA54B21E811E for ; Tue, 3 Sep 2013 08:22:53 -0700 (PDT) Received: from localhost ([127.0.0.1]:58663 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsRN-0000qW-Tu; Tue, 03 Sep 2013 17:22:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:22:49 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/clue/trac/ticket/20#comment:3 Message-ID: <083.52c00f51edddc3ade7645e82785b34d8@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:23:10 -0000 #20: Action item vii: Rejecting Configure Changes (by mary.ietf.barnes@gmail.com): * component: framework => charter Old description: > Action item vii from 19-20 Sept. 2012 interim. > > Andy: Add text to Framework for rejecting Configure > > As discussed at virtual interim on May 21st, 2013: > http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- > interim-2013-clue-1 > this needs to be mentioned in the framework, so that the subsequent > actions can be described. (E.g., does the prior configure remain in > effect?) > > The details of how this is communicated belong in the solution. New description: Action item vii from 19-20 Sept. 2012 interim. Andy: Add text to Framework for rejecting Configure As discussed at virtual interim on May 21st, 2013: http://www.ietf.org/proceedings/interim/2013/05/21/clue/minutes/minutes- interim-2013-clue-1 this needs to be mentioned in the framework, so that the subsequent actions can be described. (E.g., does the prior configure remain in effect?) The details of how this is communicated belong in the solution. As discussed at IETF-87, this ticket is being reassigned to the signaling/solution document (being parked as a charter item until we have a WG signaling document. -- -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:23:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6321E8158 for ; Tue, 3 Sep 2013 08:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkmqBL9oMaKR for ; Tue, 3 Sep 2013 08:23:40 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E347621E8120 for ; Tue, 3 Sep 2013 08:23:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:58732 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsS4-0007o5-4x; Tue, 03 Sep 2013 17:23:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:23:32 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/clue/trac/ticket/20#comment:4 Message-ID: <083.86376b5a59707190cd54f8df0ce08e5d@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mark.duckworth@polycom.com, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:23:41 -0000 #20: Action item vii: Rejecting Configure Changes (by mary.ietf.barnes@gmail.com): * cc: apeppere@gmail.com (removed) -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mark.duckworth@polycom.com Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:24:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F2821E8162 for ; Tue, 3 Sep 2013 08:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfNtVPPXqOXe for ; Tue, 3 Sep 2013 08:24:33 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D118021E814E for ; Tue, 3 Sep 2013 08:24:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:58889 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsT0-0003kB-Oc; Tue, 03 Sep 2013 17:24:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:24:30 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/20#comment:5 Message-ID: <083.9bebfee3cf405354f2285da3811d9e26@trac.tools.ietf.org> References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:24:39 -0000 #20: Action item vii: Rejecting Configure Changes (by mary.ietf.barnes@gmail.com): * owner: mark.duckworth@polycom.com => mary.ietf.barnes@gmail.com * severity: - => Candidate WG Document -- -------------------------------------+------------------------------------- Reporter: | Owner: mary.ietf.barnes@gmail.com | mary.ietf.barnes@gmail.com Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:27:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AA711E80F4 for ; Tue, 3 Sep 2013 08:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjwQEsswG+lM for ; Tue, 3 Sep 2013 08:27:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 47CC911E80E0 for ; Tue, 3 Sep 2013 08:27:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:59125 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsWH-0005HO-LB; Tue, 03 Sep 2013 17:27:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:27:53 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/clue/trac/ticket/43 Message-ID: <068.78bc5564d1a103b791e047ecdd0d5221@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20130903152758.47CC911E80E0@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:27:58 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #43: Attributes with Consumer Choices X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:27:59 -0000 #43: Attributes with Consumer Choices As discussed at IETF-87: http://www.ietf.org/proceedings/87/minutes/minutes-87-clue Currently, provider can Advertise multiple values for scene-switch-policy, and Consumer can choose in the Configure message. Proposal is to not allow consumer to chose the value. Provider can advertise different captures with different values. This also impacts Data Model. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From pkyzivat@alum.mit.edu Tue Sep 3 08:28:47 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFC421E804B for ; Tue, 3 Sep 2013 08:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.339 X-Spam-Level: X-Spam-Status: No, score=-0.339 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AigJ25bfr5mH for ; Tue, 3 Sep 2013 08:28:42 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 3648611E80E0 for ; Tue, 3 Sep 2013 08:28:42 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id LaoE1m0030SCNGk53fUhSt; Tue, 03 Sep 2013 15:28:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id LfUh1m00a3ZTu2S3VfUhPP; Tue, 03 Sep 2013 15:28:41 +0000 Message-ID: <52260028.5000202@alum.mit.edu> Date: Tue, 03 Sep 2013 11:28:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE Content-Type: multipart/alternative; boundary="------------010603060107030109010409" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378222121; bh=tGAXd0C0Y1uAakq9Sn+ifLleUEthV54klFnNUIX2PVg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=B5GUG/Q2npV2mJ4ysvSixHoh3eQE2DGZhKpghwqVm1WU+vONgXxYnO3wpgwum3Ua0 40lCPdgRnqhvnBQUuJzqHxxgRVXkOu/zpQyQL7dYdld6UlPr2CQ7x89VEm5vqgY5a6 cvNxvlibpRH+YbCRhF25Uly1H64Y4CHBTRKeTe8VK6n/q5lXnQj+jIuzjgSyaDOUFL i4NnESqD0CLacx2vSpTbpKA/ukQKLAxmX4Vz5XuKQ213KaKl2v9ufqUTR3ijnp1dhr zc4EyMiFGRQqJ7MND00LA8pFsj0axPsVruLcJOw0hB6ex8JjO50Me1t1+1O4QtYibh pLJ3+DRngBYWQ== Subject: [clue] MEETING INFO: CLUE WG Signaling Design Team, Tues Sept 10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:28:47 -0000 This is a multi-part message in MIME format. --------------010603060107030109010409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit The first of the new series of design team meetings will be Tuesday Sept 10. (See below for time.) The new series is concentrating on the CLUE signaling. This meeting is opento all who are willing to contribute. Contribute means that you volunteer to provide text. We have a set of volunteers, and they are the people I expect to have call in: Simon, Roberta, Christer, Rob, Roni, and maybe Jonathan. (Others willing to contribute are welcome. If you'd like to join, please contact meso we can discuss your role.) For this first session I've promised to take the lead on the issue of: Approach to versioning/options/extensions. I don't expect to have text in the draft for this by then, but hope to have some specific proposals. (I'm still thinking about the details.) ========================== Clue Working Group meeting information: Topic: CLUE WG Signaling Design Team Date: Every Tuesday, from Tuesday, September 10, 2013 to no end date Time: 8:30 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 646 255 438 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:646 255 438 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&ICS=UMI&LD=1&RD=2&ST=1&SHA2=AAAAAs4wxodSid4H6UBgrF-kJ6kSpPUMhaRJyeYRYM3ZPM23&RT=MiM3 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. http://www.webex.com CCP:+16504793208x646255438# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --------------010603060107030109010409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit The first of the new series of design team meetings will be Tuesday Sept 10.
(See below for time.)

The new series is concentrating on the CLUE signaling.
This meeting is open to all who are willing to contribute.
Contribute means that you volunteer to provide text.

We have a set of volunteers, and they are the people I expect to have call in:
Simon, Roberta, Christer, Rob, Roni, and maybe Jonathan.
(Others willing to contribute are welcome. If you'd like to join, please contact me so we can discuss your role.)

For this first session I've promised to take the lead on the issue of: Approach to versioning/options/extensions.
I don't expect to have text in the draft for this by then, but hope to have some specific proposals. (I'm still thinking about the details.)

==========================
Clue Working Group meeting information:

Topic: CLUE WG Signaling Design Team
Date: Every Tuesday, from Tuesday, September 10, 2013 to no end date
Time: 8:30 am, Central Daylight Time (Chicago, GMT-05:00)
Meeting Number: 646 255 438
Meeting Password: 1234


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&RT=MiM3
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: 1234
4. Click "Join".
5. Follow the instructions that appear on your screen.

To view in other time zones or languages, please click the link:
https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&ORT=MiM3

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:646 255 438

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You can contact me at:
clue-chairs@tools.ietf.org


To update this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&ICS=UMI&LD=1&RD=2&ST=1&SHA2=AAAAAs4wxodSid4H6UBgrF-kJ6kSpPUMhaRJyeYRYM3ZPM23&RT=MiM3


WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link:
https://ietf.webex.com/ietf/meetingcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.

http://www.webex.com

CCP:+16504793208x646255438#

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.
--------------010603060107030109010409-- From trac+clue@trac.tools.ietf.org Tue Sep 3 08:30:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94F521E811E for ; Tue, 3 Sep 2013 08:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypUpi3ZWa3EQ for ; Tue, 3 Sep 2013 08:30:12 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 373AD21E804B for ; Tue, 3 Sep 2013 08:30:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:59296 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsYR-0002pq-Pj; Tue, 03 Sep 2013 17:30:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:30:07 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/clue/trac/ticket/44 Message-ID: <068.2f5865fc015e927b98af4ddc9e1f5469@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20130903153012.373AD21E804B@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:30:12 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #44: Remove contradiction wrt responding to Advertisement with Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:30:12 -0000 #44: Remove contradiction wrt responding to Advertisement with Configure As discussed at IETF-87: http://www.ietf.org/proceedings/87/minutes/minutes-87-clue And per the mailing list discussion: http://www.ietf.org/mail- archive/web/clue/current/msg02684.html Action: Markt to post a proposal to mailing list to remove the details from the framework. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: framework | Version: Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:31:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFBF21F9A90 for ; Tue, 3 Sep 2013 08:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WZCfUmOfzn6 for ; Tue, 3 Sep 2013 08:31:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 45CFA21F9A72 for ; Tue, 3 Sep 2013 08:31:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:59383 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsZS-0002z7-6J; Tue, 03 Sep 2013 17:31:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:31:10 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/clue/trac/ticket/44#comment:1 Message-ID: <083.052aa9d179c600811a21a6c7e3b62144@trac.tools.ietf.org> References: <068.2f5865fc015e927b98af4ddc9e1f5469@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <068.2f5865fc015e927b98af4ddc9e1f5469@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Resent-Message-Id: <20130903153119.45CFA21F9A72@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:31:19 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #44: Remove contradiction wrt responding to Advertisement with Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:31:20 -0000 #44: Remove contradiction wrt responding to Advertisement with Configure Changes (by mary.ietf.barnes@gmail.com): * severity: Active WG Document => Candidate WG Document Old description: > As discussed at IETF-87: > http://www.ietf.org/proceedings/87/minutes/minutes-87-clue > > And per the mailing list discussion: http://www.ietf.org/mail- > archive/web/clue/current/msg02684.html > > Action: Markt to post a proposal to mailing list to remove the details > from the framework. New description: As discussed at IETF-87: http://www.ietf.org/proceedings/87/minutes/minutes-87-clue And per the mailing list discussion: http://www.ietf.org/mail- archive/web/clue/current/msg02684.html Action: Mark to post a proposal to mailing list to remove the details from the framework. This should be changed to a Signaling/Solution document issue once we have a WG document -- -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | framework@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: framework | Version: Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From ron.even.tlv@gmail.com Tue Sep 3 08:32:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB1E21F9CCC for ; Tue, 3 Sep 2013 08:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqoc8dz1jEUt for ; Tue, 3 Sep 2013 08:32:19 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id EBC3E21F9C3A for ; Tue, 3 Sep 2013 08:32:18 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hm2so940788wib.12 for ; Tue, 03 Sep 2013 08:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=RwdINJuMLglSlou5lflsdvVOrwFfZ3UR/0tltLmEeoI=; b=dHlB4bJW19nTc0IK+jeeXpg1YhRxIEQK1542oBS4K7vAATRtecvx2ifLUDWsiG36X8 DN20jtm7EWzViZMfjpGACNBht2ic9bSrcbL/FKSq77azTAeu8vxfRSpKs7Z9JXkmWhLj qXI1zvjZRKxntVbXJnAWKsQkPjATEfNJh94FxkxFlGOUZcCLwqz5P0Vq7v7bggY+W+gj Kof7JMkMw6h0nRdP7GOq+GnnHubtPCrSkSBGGH7Ove3G4ifGm/Vq8hCOvSMi4WPg4WH1 AWcn6X2H/f5FvrsDKx5tTg2mphpKurpO2H0+XZsZBkjKPR3frSWn8JGUtSkUvkMqKN7G Kr0A== X-Received: by 10.194.240.164 with SMTP id wb4mr650100wjc.70.1378222338039; Tue, 03 Sep 2013 08:32:18 -0700 (PDT) Received: from RoniE (bzq-79-181-232-77.red.bezeqint.net. [79.181.232.77]) by mx.google.com with ESMTPSA id fz8sm26574373wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Sep 2013 08:32:17 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Tue, 3 Sep 2013 18:29:39 +0300 Message-ID: <02c701cea8ba$69891ce0$3c9b56a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C8_01CEA8D3.8ED78D60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3dWs4erzQY5QLLb9yNsglWNAwqZpiiamw Content-Language: en-us Cc: 'Roni Even' Subject: Re: [clue] Preparing PROTO Write-up for Use case document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 15:32:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C8_01CEA8D3.8ED78D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mary, I am OK with the text for section 2 and can update the document if no objections and fix the nits Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 03 September, 2013 6:07 PM To: CLUE Cc: Roni Even Subject: [clue] Preparing PROTO Write-up for Use case document Hi all, In the process of re-reviewing the use cases document in preparation of the PROTO write-up, I came across the following nits and a couple minor issues that I would like to discuss with the WG. Thanks, Mary. Minor issues: ------------------- - Section 2, first two paragraphs after numbered list. I struggled a little bit with this text (which is more of a problem statement) in a section that's providing an overview of scenarios. I would suggest to move the first of those two paragraphs into section 1 and delete that 2nd paragraph (in section 2) as I think what's important is the current last sentence of the 2nd paragraph in section 1. Thus, I'm suggesting changing the 2nd paragraph in section 1 as follows: OLD: Although telepresence systems are based on open standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor's protocol to another. A standard way of describing the multiple streams constituting the media flows and the fundamental aspects of their behavior, would allow telepresence systems to interwork. NEW: Although telepresence systems are based on open standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor's protocol to another. The basic features that give telepresence its distinctive characteristics are implemented in disparate ways in different systems. Currently Telepresence systems from diverse vendors interoperate to some extent, but this is not supported in a standards based fashion. Interworking requires that translation and transcoding devices be included in the architecture. Such devices increase latency, reducing the quality of interpersonal interaction. Use of these devices is often not automatic; it frequently requires substantial manual configuration and a detailed understanding of the nature of underlying audio and video streams. This state of affairs is not acceptable for the continued growth of telepresence - telepresence systems should have the same ease of interoperability as do telephones. Thus, a standard way of describing the multiple streams constituting the media flows and the fundamental aspects of their behavior, would allow telepresence systems to interwork. - Section 3.4, 5th paragraph : This seems misplaced as there isn't anywhere else in the document where we talk about protocols (this is something which would really be more appropriately discussed in the solution documents). I would suggest to delete this paragraph. Nits: ------- - Section 1, 3rd paragraph, 1st sentence: "draft"->"document", "requirements will be derived" -> "requirements are derived" - Section 1, last paragraph: Need to add two spaces after "This document structure is as follows:" - Section 2, "users we will call participant cameras" -> "users are referred to as participant cameras" (consistent with wording a couple sentences down) - Section 3, first sentence. Adding spacing after the sentence. - Section 3.7, first paragraph, 1st sentence. Adding spacing after the sentence. - Section 3.9, first paragraph, last sentence. This is awkwardly worded. I suggest changing: "assist the process of the surgery" to simply "assist in the surgery" or "assist in the surgical process" - Section 4. 1st para. "draft" -> "document" ------=_NextPart_000_02C8_01CEA8D3.8ED78D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mary,

I am OK with the text for section 2 and can update the document if no = objections and fix the nits

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 03 September, 2013 6:07 PM
To: = CLUE
Cc: Roni Even
Subject: [clue] Preparing PROTO = Write-up for Use case document

 

Hi = all,

 

In the process of re-reviewing the use cases document = in preparation of the PROTO write-up, I came across the following nits = and a couple minor issues that I would like to discuss with the = WG. 

 

Thanks,

Mary.

 

Minor issues:

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

 

- = Section 2, first two paragraphs after numbered list.  I struggled a = little bit with this text (which is more of a problem statement) in a = section that's providing an overview of scenarios. I would suggest to = move the first of those two paragraphs into section 1 and delete that = 2nd paragraph (in section 2)  as I think what's important is the = current last sentence of the 2nd paragraph in section 1.  Thus, I'm = suggesting changing the 2nd paragraph in section 1 as = follows:

OLD:

Although telepresence systems are based on open = standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the = H.323[ITU.H323] suite of protocols, they cannot easily interoperate with = each other without operator assistance and expensive additional = equipment which translates from one vendor's protocol to another. A = standard way of describing the multiple streams constituting the media = flows and the fundamental aspects of their behavior, would allow = telepresence systems to = interwork.

 

NEW: 

Although telepresence systems are based on open = standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the = H.323[ITU.H323] suite of protocols, they cannot easily interoperate with = each other without operator assistance and expensive additional = equipment which translates from one vendor's protocol to = another. 

The = basic features that give telepresence its distinctive = characteristics are implemented in disparate ways in = different = systems. Currently Telepresence systems from diverse = vendors = interoperate to some extent, but this is not supported = in a standards = based = fashion. Interworking requires that translation and = transcoding devices be included in the architecture. = Such devices = increase latency, reducing the quality of = interpersonal interaction. = Use of = these devices is often not automatic; it frequently = requires = substantial manual configuration and a detailed = understanding of the = nature = of underlying audio and video streams. This state of = affairs = is not = acceptable for the continued growth of telepresence - = telepresence systems should have the same ease of = interoperability as = do = telephones. Thus, a standard way of describing the multiple streams = constituting the media flows and the fundamental aspects of their = behavior, would allow telepresence systems to = interwork.

 

- = Section 3.4, 5th paragraph :  This seems misplaced as there isn't = anywhere else in the document where we talk about protocols (this is = something which would really be more appropriately discussed in the = solution documents).  I would suggest to delete this paragraph. =  

 

Nits:

-------

- Section 1, 3rd paragraph, 1st sentence: = "draft"->"document", "requirements will be = derived" -> "requirements are = derived"

- Section 1, = last paragraph: Need to add two spaces after "This document = structure is as follows:"   

- Section 2, "users we will call participant = cameras" -> "users are referred to as participant = cameras"  (consistent with wording a couple sentences = down) 

- Section 3, = first sentence.  Adding spacing after the = sentence. 

- Section = 3.7, first paragraph, 1st sentence.  Adding spacing after the = sentence.

- Section 3.9, = first paragraph, last sentence.  This is awkwardly worded. I = suggest changing: "assist the process of the surgery" to = simply "assist in the surgery" or "assist in the surgical = process" 

- = Section 4.  1st para. "draft" -> = "document"

------=_NextPart_000_02C8_01CEA8D3.8ED78D60-- From trac+clue@trac.tools.ietf.org Tue Sep 3 08:34:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD5B21F9CCC for ; Tue, 3 Sep 2013 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoOrTI-K1Xgf for ; Tue, 3 Sep 2013 08:34:05 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0930D21E814E for ; Tue, 3 Sep 2013 08:34:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:59586 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGscB-00009c-CI; Tue, 03 Sep 2013 17:33:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:33:59 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/12#comment:2 Message-ID: <083.0f72d8a6272f15f3fed8d6d59b614e13@trac.tools.ietf.org> References: <068.d15391187319f8b7b89764b056e281a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <068.d15391187319f8b7b89764b056e281a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20130903153401.0930D21E814E@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:34:00 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #12: Signaling: what data can be carried in SDP? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:34:06 -0000 #12: Signaling: what data can be carried in SDP? Changes (by mary.ietf.barnes@gmail.com): * severity: - => Candidate WG Document -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: new Priority: blocker | Milestone: milestone1 Component: charter | Version: 1.0 Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:35:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6D521E8176 for ; Tue, 3 Sep 2013 08:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tznfTSRwBBrs for ; Tue, 3 Sep 2013 08:35:29 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B762B21E8161 for ; Tue, 3 Sep 2013 08:35:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:59793 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsdY-0008Ks-AY; Tue, 03 Sep 2013 17:35:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-rtp-mapping@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:35:24 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/clue/trac/ticket/11#comment:1 Message-ID: <083.566b0e1247a5d8a21c9585a4e907605d@trac.tools.ietf.org> References: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <068.5ca029063d5e7080dd9f9169d703adcf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-rtp-mapping@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonathan@vidyo.com, roni.even@mail01.huawei.com Resent-Message-Id: <20130903153528.B762B21E8161@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:35:28 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #11: RTP header extension for Capture ID X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:35:30 -0000 #11: RTP header extension for Capture ID Changes (by mary.ietf.barnes@gmail.com): * owner: clue-chairs@tools.ietf.org => draft-ietf-clue-rtp- mapping@tools.ietf.org * component: charter => rtp-mapping * severity: Candidate WG Document => Active WG Document Old description: > Is an RTP header extension needed to transport a capture ID (per draft- > lennox-clue-rtp-usage-04)? New description: Is an RTP header extension needed to transport a capture ID? -- -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue-rtp- mary.ietf.barnes@gmail.com | mapping@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-mapping | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: RTP | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:38:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A024821E8130 for ; Tue, 3 Sep 2013 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp0kk6jkjYHn for ; Tue, 3 Sep 2013 08:38:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6454521F9E48 for ; Tue, 3 Sep 2013 08:38:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:59843 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsgS-0000Oh-1g; Tue, 03 Sep 2013 17:38:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:38:23 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/39#comment:2 Message-ID: <083.b7b17bb1edae8fe9087c8996887dbedf@trac.tools.ietf.org> References: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <068.fd110beaf6c8e421030b8870ebecf4bf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130903153828.6454521F9E48@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:38:28 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #39: OPEN-3 Conference modes [REQMT-14] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:38:30 -0000 #39: OPEN-3 Conference modes [REQMT-14] Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * version: => 1.0 * resolution: => fixed Comment: This issue has been resolved in the -05 version of the requirements per mailing list proposal (by Christian): http://www.ietf.org/mail- archive/web/clue/current/msg02841.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: defect | requirements@tools.ietf.org Priority: major | Status: closed Component: telepresence- | Milestone: milestone1 requirements | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:40:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53C321E8143 for ; Tue, 3 Sep 2013 08:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ven9ZvzBiRTB for ; Tue, 3 Sep 2013 08:40:30 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3B93C21E8130 for ; Tue, 3 Sep 2013 08:40:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:59943 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsiQ-0001yj-QZ; Tue, 03 Sep 2013 17:40:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:40:26 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/38#comment:2 Message-ID: <083.e1d531863ff9cca81d05937c26ba1e46@trac.tools.ietf.org> References: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <068.3505861e0ea14b2d12ee55c27b44b7ea@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-telepresence-requirements@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, mary.ietf.barnes@gmail.com, stephen.botzko@polycom.com Resent-Message-Id: <20130903154030.3B93C21E8130@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:40:30 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #38: OPEN-2 Reference to Rendering [REQMT-3b] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:40:31 -0000 #38: OPEN-2 Reference to Rendering [REQMT-3b] Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue was resolved by removing this requirement per the mailing list discussion: http://www.ietf.org/mail-archive/web/clue/current/msg02770.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mary.ietf.barnes@gmail.com | telepresence- Type: enhancement | requirements@tools.ietf.org Priority: major | Status: closed Component: telepresence- | Milestone: milestone1 requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:42:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA55411E81E4 for ; Tue, 3 Sep 2013 08:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpDbWRPORRam for ; Tue, 3 Sep 2013 08:42:35 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27D11E81CE for ; Tue, 3 Sep 2013 08:42:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:59995 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsjx-0003xI-Kd; Tue, 03 Sep 2013 17:42:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: even.roni@huawei.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:42:01 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/3#comment:3 Message-ID: <078.e65b45eba5604e8d7aeca3eac3bac2b6@trac.tools.ietf.org> References: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <063.989fef5c8859eb1ed5eaeeaac3cf1759@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: even.roni@huawei.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #3: Use case for an RTCWEB client X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:42:35 -0000 #3: Use case for an RTCWEB client Changes (by mary.ietf.barnes@gmail.com): * status: new => closed * resolution: => fixed Comment: This issue is being closed as this is note a core CLUE WG requirement and may be considered at a future date. -- ------------------------------------+----------------------------------- Reporter: pkyzivat@alum.mit.edu | Owner: even.roni@huawei.com Type: task | Status: closed Priority: major | Milestone: Component: telepresence-use-cases | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+----------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:47:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA37C11E81F4 for ; Tue, 3 Sep 2013 08:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v01zq+NTntJ3 for ; Tue, 3 Sep 2013 08:47:27 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 404F511E80E0 for ; Tue, 3 Sep 2013 08:47:27 -0700 (PDT) Received: from localhost ([127.0.0.1]:60556 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsp9-0005OM-TO; Tue, 03 Sep 2013 17:47:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:47:23 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/clue/trac/ticket/24#comment:2 Message-ID: <083.1b630e636d5de1ee1aa6862a3afaea40@trac.tools.ietf.org> References: <068.c48fbd7adf469a2fed5e232a09e9eaf6@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <068.c48fbd7adf469a2fed5e232a09e9eaf6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, keith.drage@alcatel-lucent.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:47:27 -0000 #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line Changes (by mary.ietf.barnes@gmail.com): * component: telepresence-use-cases => charter * severity: - => Candidate WG Document Comment: This is being changed to a charter issue for now as it's a very protocol specific scenario and really is something that should be discussed in a solution document as opposed to the CLUE WG use cases document which is higher level scenarios. We will change the ticket to the solution document once we have a WG document. -- ----------------------------------------+-------------------------- Reporter: mary.ietf.barnes@gmail.com | Owner: Keith Drage Type: task | Status: new Priority: minor | Milestone: milestone1 Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: | ----------------------------------------+-------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Tue Sep 3 08:48:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEDF111E81F4 for ; Tue, 3 Sep 2013 08:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NxjwQs+Fksh for ; Tue, 3 Sep 2013 08:48:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1F811E80E0 for ; Tue, 3 Sep 2013 08:48:42 -0700 (PDT) Received: from localhost ([127.0.0.1]:60601 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VGsqN-0003st-RM; Tue, 03 Sep 2013 17:48:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Tue, 03 Sep 2013 15:48:39 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/24#comment:3 Message-ID: <083.5c0e84c946a37f4378c018f105ba5e6c@trac.tools.ietf.org> References: <068.c48fbd7adf469a2fed5e232a09e9eaf6@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <068.c48fbd7adf469a2fed5e232a09e9eaf6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, keith.drage@alcatel-lucent.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20130903154842.3A1F811E80E0@ietfa.amsl.com> Resent-Date: Tue, 3 Sep 2013 08:48:42 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 15:48:42 -0000 #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line Changes (by mary.ietf.barnes@gmail.com): * cc: keith.drage@alcatel-lucent.com (removed) * owner: Keith Drage => clue-chairs@tools.ietf.org -- -------------------------------------+------------------------------------- Reporter: | Owner: clue- mary.ietf.barnes@gmail.com | chairs@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: milestone1 Component: charter | Version: Severity: Candidate WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From pkyzivat@alum.mit.edu Tue Sep 3 13:01:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0721F9AD8 for ; Tue, 3 Sep 2013 13:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.338 X-Spam-Level: X-Spam-Status: No, score=-0.338 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oTp7xwHSA0W for ; Tue, 3 Sep 2013 13:01:26 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0939521F8267 for ; Tue, 3 Sep 2013 13:01:25 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta04.westchester.pa.mail.comcast.net with comcast id Lfo41m0050vyq2s54k1F58; Tue, 03 Sep 2013 20:01:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id Lk1F1m0023ZTu2S3Rk1FEV; Tue, 03 Sep 2013 20:01:15 +0000 Message-ID: <5226400A.1040402@alum.mit.edu> Date: Tue, 03 Sep 2013 16:01:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378238475; bh=tngocc2W/cJtZTOXfHSNeXByDmw2ZxIUZbvmP5FRA3o=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=leezmhRr7DhlV5lPtFtv6sbCzlR3dfrjt2jLyxYeZO/3nuciOcb4rN+vue3+7KzhP 81RxwoxgMRW7OW5osqVqUAluHSn0+1cjfLi1zfrFAp6nPPMIwSW3i2jk/fmeEUb8ET r73/xVh3y1zJov+VUgDK9C+wKLNAd5j7OuTDayg4huj6lgTKqgRl1RjvYAVVrffgTb EE6OP21jDGjWPPXomVRhHE6OXIvuImqqzk3mNFefXKRKPVlbEdpbO3NtsrQLsKKFit 0RsMq7+CncDpPOvcYn5MltCo0M7BdpYVZJLb/c9fUMHUbodjOp+Uve/kdq7LH0FnYn p/lXzDtghyPug== Cc: CLUE Subject: Re: [clue] CLUE Framework comments and general thoughts on organization of other documents X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 20:01:32 -0000 On 8/28/13 6:24 PM, Mary Barnes wrote: > Here is another more general set of comments on the framework document. > > Putting together text for the security requirements section for the > framework has made me consider how we have the documents structured and > the dependencies. > > 1) The CLUE Framework document needs to be standards track (it's already > a normative reference in the signaling document) as it outlines > normative implementation details. So, the document needs to be revised > to ensure that "must"s are "MUST"s and some text may need to be changed > to be normative - e.g., "can be" -> MAY, etc. Lets think about this. Do we *want* the framework to be normative? Or are you just saying it needs to be normative because of how we have the other documents structured? If we don't want it to be normative, then we just need to take steps to move all the normative stuff elsewhere, and leave non-normative abstractions/platitudes in the framework. (I meant that in a good way.) I don't have a strong feeling about it. But in general I would expect that a framework might not need to be normative. Thanks, Paul > 2) As we've discussed we probably will not publish the Framework until > the other detailed solution documents are near completion. [Although, > it is not a problem to have informative references as works in > progress.] So, I think that the framework document should be more > explicit about referencing the solution documents. One reason I think > this is that some of the details are very specific (e.g., the use of the > names of specific data elements). Also, it has been a while since I've > carefully reviewed the framework from start to finish and it seems to me > that it leaves you hanging without having references to where all the > details are found. Adding that will also make it easier to reference > specifics in the security analysis and be able to re-assure the security > folks that the issues are addressed in the other solution > documents. Thus, I think the framework would be a good document to > outline the solution documents (e.g., there is already an indirect > reference to the RTP document). > > Thanks, > Mary. > > > From mary.ietf.barnes@gmail.com Tue Sep 3 13:14:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9999811E815C for ; Tue, 3 Sep 2013 13:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7Ej6s9R9qce for ; Tue, 3 Sep 2013 13:14:04 -0700 (PDT) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 381F311E8140 for ; Tue, 3 Sep 2013 13:14:01 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id k18so2863172qcv.13 for ; Tue, 03 Sep 2013 13:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZCCqa2vARmnfyOj29toV/P5yP4NUeaXHHnDmkq6+OT0=; b=hsnWrXERYvfgEsVXQZYbBzg3gqHgoUTKWJg3cZL1d2ml5cwucYrlq8m7PDiDIyB8LL D0VA84ucab2BZK/xQ5idx46l1VSz1uxkqoo8O3LDbT40AIc++urw2fh21S8w4aReWibT iHVCWqw+t+VFtbF7JpgRZ4FRDMCsy4x7ZUdjzLRkSOE/Yhc3bIfTANB+8XJ6n3st5jXa fHfLO3IXRTlhGK7u1s0YIlRQW+W6t3dVFFrKo2yVlJBs8CWRvyXBQ1h8zwLS9lDg+fZw ngQWC4fK4Siyk8vPksOYWl6R9v3PkovZ8vGth8IyRpGV+lTnThXRZEQrEVwjuPA1WVlo Y3Gg== MIME-Version: 1.0 X-Received: by 10.49.105.74 with SMTP id gk10mr40355790qeb.8.1378239240635; Tue, 03 Sep 2013 13:14:00 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 3 Sep 2013 13:14:00 -0700 (PDT) In-Reply-To: <5226400A.1040402@alum.mit.edu> References: <5226400A.1040402@alum.mit.edu> Date: Tue, 3 Sep 2013 15:14:00 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b6777aa5a8aa804e580540a Cc: CLUE Subject: Re: [clue] CLUE Framework comments and general thoughts on organization of other documents X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 20:14:05 -0000 --047d7b6777aa5a8aa804e580540a Content-Type: text/plain; charset=ISO-8859-1 I should clarify and qualify that I don't think there are a lot of changes at all in terms of normative text. I gave one example in my response to Keith. If we want to make the FW non-normative, I really think you are going to remove a whole lot more than I'm suggesting should be updated to make the document normative. We have iterated over the FW many, many times in terms of what belongs and what doesn't. I think we almost have it right. I don't see that it causes harm to make it normative and in the end, I believe it provides an appropriate structure around the solution. Mary. On Tue, Sep 3, 2013 at 3:01 PM, Paul Kyzivat wrote: > On 8/28/13 6:24 PM, Mary Barnes wrote: > >> Here is another more general set of comments on the framework document. >> >> Putting together text for the security requirements section for the >> framework has made me consider how we have the documents structured and >> the dependencies. >> >> 1) The CLUE Framework document needs to be standards track (it's already >> a normative reference in the signaling document) as it outlines >> normative implementation details. So, the document needs to be revised >> to ensure that "must"s are "MUST"s and some text may need to be changed >> to be normative - e.g., "can be" -> MAY, etc. >> > > Lets think about this. Do we *want* the framework to be normative? Or are > you just saying it needs to be normative because of how we have the other > documents structured? If we don't want it to be normative, then we just > need to take steps to move all the normative stuff elsewhere, and leave > non-normative abstractions/platitudes in the framework. (I meant that in a > good way.) > > I don't have a strong feeling about it. But in general I would expect that > a framework might not need to be normative. > > Thanks, > Paul > > > 2) As we've discussed we probably will not publish the Framework until >> the other detailed solution documents are near completion. [Although, >> it is not a problem to have informative references as works in >> progress.] So, I think that the framework document should be more >> explicit about referencing the solution documents. One reason I think >> this is that some of the details are very specific (e.g., the use of the >> names of specific data elements). Also, it has been a while since I've >> carefully reviewed the framework from start to finish and it seems to me >> that it leaves you hanging without having references to where all the >> details are found. Adding that will also make it easier to reference >> specifics in the security analysis and be able to re-assure the security >> folks that the issues are addressed in the other solution >> documents. Thus, I think the framework would be a good document to >> outline the solution documents (e.g., there is already an indirect >> reference to the RTP document). >> >> Thanks, >> Mary. >> >> >> >> > --047d7b6777aa5a8aa804e580540a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I should clarify and qualify that I don't think there = are a lot of changes at all in terms of normative text. =A0I gave one examp= le in my response to Keith. =A0

If we want to make the F= W non-normative, I really think you are going to remove a whole lot more th= an I'm suggesting should be updated to make the document normative. =A0= We have iterated over the FW many, many times in terms of what belongs and = what doesn't. =A0I think we almost have it right. =A0 I don't see t= hat it causes harm to make it normative and in the end, I believe it provid= es an appropriate structure around the solution.=A0

Mary.=A0


On Tue, Sep 3, 2013 at 3:01 PM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
On 8/28/13 6:24 PM, Mary B= arnes wrote:
Here is another more general set of comments on the framework document.

Putting together text for the security requirements section for the
framework has made me consider how we have the documents structured and
the dependencies.

1) The CLUE Framework document needs to be standards track (it's alread= y
a normative reference in the signaling document) as it outlines
normative implementation details. =A0So, the document needs to be revised to ensure that "must"s are "MUST"s and some text may ne= ed to be changed
to be normative - e.g., "can be" -> MAY, etc.

Lets think about this. Do we *want* the framework to be normative? Or are y= ou just saying it needs to be normative because of how we have the other do= cuments structured? If we don't want it to be normative, then we just n= eed to take steps to move all the normative stuff elsewhere, and leave non-= normative abstractions/platitudes in the framework. (I meant that in a good= way.)

I don't have a strong feeling about it. But in general I would expect t= hat a framework might not need to be normative.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


2) As we've discussed we probably will not publish the Framework until<= br> the other detailed solution documents are near completion. =A0[Although, it is not a problem to have informative references as works in
progress.] =A0 So, I =A0think that the framework document should be more explicit about referencing the solution documents. =A0One reason I think this is that some of the details are very specific (e.g., the use of the names of specific data elements). =A0Also, it has been a while since I'= ve
carefully reviewed the framework from start to finish and it seems to me that it leaves you hanging without having references to where all the
details are found. Adding that will also make it easier to reference
specifics in the security analysis and be able to re-assure the security folks that the issues are addressed in the other solution
documents. Thus, I think the framework would be a good document to
outline the solution documents (e.g., there is already an indirect
reference to the RTP document).

Thanks,
Mary.





--047d7b6777aa5a8aa804e580540a-- From pkyzivat@alum.mit.edu Tue Sep 3 13:43:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB24021E8085 for ; Tue, 3 Sep 2013 13:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.341 X-Spam-Level: X-Spam-Status: No, score=-0.341 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnrGr7LJ6XYT for ; Tue, 3 Sep 2013 13:43:23 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id D3F0C21E8083 for ; Tue, 3 Sep 2013 13:43:22 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta07.westchester.pa.mail.comcast.net with comcast id Lbk01m0010SCNGk57kjNdX; Tue, 03 Sep 2013 20:43:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id LkjN1m00T3ZTu2S3VkjN2p; Tue, 03 Sep 2013 20:43:22 +0000 Message-ID: <522649EA.4030400@alum.mit.edu> Date: Tue, 03 Sep 2013 16:43:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <5226400A.1040402@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378241002; bh=gm1dcs4R3ieWLkJ+fjFjVtv53C9gCSB21mDbi4xo9OE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Mij0Fnk1k4aFYi+n+dAa77AOe70KMis5B3qZPgHppL+ZS1Zfk6o0jj5vCzXBt49LI 1b80G92K+dLzPaq3Iq6Jk3XckRZgYk+Kz6X9qDbi8Hwymnw0UKM1oEmaXy2eCOrMGn Iek5QyvNCB0WTeO4N/hWcvhp5eh173rbu9CUn13QZoZWRgBj6jOr8omztEtQDogfXr t8b8iOUNHyIqOrzU9nEiW/+UJETlQUWsS/n0V8uB/OfucSgNUYags/dJVdnh5ehHqo 1P24FQl8tM9L03Fez3V+nwXJjpSBreKtlFGDsmqDHgMoDzxmWU19XnlCwboXDjb9PO mTHvrio9igGRQ== Cc: CLUE Subject: Re: [clue] CLUE Framework comments and general thoughts on organization of other documents X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 20:43:29 -0000 On 9/3/13 4:14 PM, Mary Barnes wrote: > I should clarify and qualify that I don't think there are a lot of > changes at all in terms of normative text. I gave one example in my > response to Keith. > > If we want to make the FW non-normative, I really think you are going to > remove a whole lot more than I'm suggesting should be updated to make > the document normative. We have iterated over the FW many, many times > in terms of what belongs and what doesn't. I think we almost have it > right. I don't see that it causes harm to make it normative and in the > end, I believe it provides an appropriate structure around the solution. Since I don't have a strong opinion one way or the other, IMO if its easy to make it normative and hard to make it non-normative, then I agree with making it normative. Thanks, Paul > Mary. > > > On Tue, Sep 3, 2013 at 3:01 PM, Paul Kyzivat > wrote: > > On 8/28/13 6:24 PM, Mary Barnes wrote: > > Here is another more general set of comments on the framework > document. > > Putting together text for the security requirements section for the > framework has made me consider how we have the documents > structured and > the dependencies. > > 1) The CLUE Framework document needs to be standards track (it's > already > a normative reference in the signaling document) as it outlines > normative implementation details. So, the document needs to be > revised > to ensure that "must"s are "MUST"s and some text may need to be > changed > to be normative - e.g., "can be" -> MAY, etc. > > > Lets think about this. Do we *want* the framework to be normative? > Or are you just saying it needs to be normative because of how we > have the other documents structured? If we don't want it to be > normative, then we just need to take steps to move all the normative > stuff elsewhere, and leave non-normative abstractions/platitudes in > the framework. (I meant that in a good way.) > > I don't have a strong feeling about it. But in general I would > expect that a framework might not need to be normative. > > Thanks, > Paul > > > 2) As we've discussed we probably will not publish the Framework > until > the other detailed solution documents are near completion. > [Although, > it is not a problem to have informative references as works in > progress.] So, I think that the framework document should be more > explicit about referencing the solution documents. One reason I > think > this is that some of the details are very specific (e.g., the > use of the > names of specific data elements). Also, it has been a while > since I've > carefully reviewed the framework from start to finish and it > seems to me > that it leaves you hanging without having references to where > all the > details are found. Adding that will also make it easier to reference > specifics in the security analysis and be able to re-assure the > security > folks that the issues are addressed in the other solution > documents. Thus, I think the framework would be a good document to > outline the solution documents (e.g., there is already an indirect > reference to the RTP document). > > Thanks, > Mary. > > > > > From Christian.Groves@nteczone.com Tue Sep 3 19:13:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CBF21E80A6 for ; Tue, 3 Sep 2013 19:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wGfiuivcXiF for ; Tue, 3 Sep 2013 19:13:40 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id A77BC21F99BD for ; Tue, 3 Sep 2013 19:13:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAMeWJlJ20a1w/2dsb2JhbAANToM8wg2BQoMYAQEBBAEBASQRGxsKEQsRAQMBAQEJFggHCQMCAQIBFR8DBggTBgIBAReHc6cXkicEj32EHQOtDQ Received: from ppp118-209-173-112.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.173.112]) by ipmail07.adl2.internode.on.net with ESMTP; 04 Sep 2013 11:43:08 +0930 Message-ID: <5226972F.6090708@nteczone.com> Date: Wed, 04 Sep 2013 12:13:03 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <02c701cea8ba$69891ce0$3c9b56a0$@gmail.com> In-Reply-To: <02c701cea8ba$69891ce0$3c9b56a0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Preparing PROTO Write-up for Use case document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 02:13:40 -0000 OK for me. Christian On 4/09/2013 1:29 AM, Roni Even wrote: > > Hi Mary, > > I am OK with the text for section 2 and can update the document if no > objections and fix the nits > > Roni > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 03 September, 2013 6:07 PM > *To:* CLUE > *Cc:* Roni Even > *Subject:* [clue] Preparing PROTO Write-up for Use case document > > Hi all, > > In the process of re-reviewing the use cases document in preparation > of the PROTO write-up, I came across the following nits and a couple > minor issues that I would like to discuss with the WG. > > Thanks, > > Mary. > > Minor issues: > > ------------------- > > - Section 2, first two paragraphs after numbered list. I struggled a > little bit with this text (which is more of a problem statement) in a > section that's providing an overview of scenarios. I would suggest to > move the first of those two paragraphs into section 1 and delete that > 2nd paragraph (in section 2) as I think what's important is the > current last sentence of the 2nd paragraph in section 1. Thus, I'm > suggesting changing the 2nd paragraph in section 1 as follows: > > OLD: > > Although telepresence systems are based on open standards such as > RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of > protocols, they cannot easily interoperate with each other without > operator assistance and expensive additional equipment which > translates from one vendor's protocol to another. A standard way of > describing the multiple streams constituting the media flows and the > fundamental aspects of their behavior, would allow telepresence > systems to interwork. > > NEW: > > Although telepresence systems are based on open standards such as > RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of > protocols, they cannot easily interoperate with each other without > operator assistance and expensive additional equipment which > translates from one vendor's protocol to another. > > The basic features that give telepresence its > distinctivecharacteristics are implemented in disparate ways in > differentsystems. Currently Telepresence systems from diverse > vendorsinteroperate to some extent, but this is not supported in a > standardsbased fashion. Interworking requires that translation > andtranscoding devices be included in the architecture. Such > devicesincrease latency, reducing the quality of interpersonal > interaction.Use of these devices is often not automatic; it frequently > requiressubstantial manual configuration and a detailed understanding > of thenature of underlying audio and video streams. This state of > affairsis not acceptable for the continued growth of telepresence > -telepresence systems should have the same ease of interoperability > asdo telephones. Thus, a standard way of describing the multiple > streams constituting the media flows and the fundamental aspects of > their behavior, would allow telepresence systems to interwork. > > - Section 3.4, 5th paragraph : This seems misplaced as there isn't > anywhere else in the document where we talk about protocols (this is > something which would really be more appropriately discussed in the > solution documents). I would suggest to delete this paragraph. > > Nits: > > ------- > > - Section 1, 3rd paragraph, 1st sentence: "draft"->"document", > "requirements will be derived" -> "requirements are derived" > > - Section 1, last paragraph: Need to add two spaces after "This > document structure is as follows:" > > - Section 2, "users we will call participant cameras" -> "users are > referred to as participant cameras" (consistent with wording a couple > sentences down) > > - Section 3, first sentence. Adding spacing after the sentence. > > - Section 3.7, first paragraph, 1st sentence. Adding spacing after > the sentence. > > - Section 3.9, first paragraph, last sentence. This is awkwardly > worded. I suggest changing: "assist the process of the surgery" to > simply "assist in the surgery" or "assist in the surgical process" > > - Section 4. 1st para. "draft" -> "document" > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Fri Sep 6 08:25:16 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4CE11E81A9 for ; Fri, 6 Sep 2013 08:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR57+3GnwTO3 for ; Fri, 6 Sep 2013 08:25:16 -0700 (PDT) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id EEC6221E81D1 for ; Fri, 6 Sep 2013 08:25:05 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x19so1279585qcw.30 for ; Fri, 06 Sep 2013 08:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=veqXa+PdyD+5TbWdBlKK8+ZIxBf9Yk5ljQXeWwcFYSI=; b=wYZCKMRgGPB9tUWIx/XkPJc1SkQwx6Z2cu0JCaZBpOa+0WKrfnaT2gmHqyHwPSYl60 iRbH3AJ0YlCTnWbCJfPBw0WmA78SgPOFPVJAx/ASN6I0W4inpTnuxXKn9pO3v9XcAisn J3lwarjthzVshWyn/fnRYwMBKFqtT+hriVII59C093cnVj5Ie6F13t8nns5g3fwz/+Kt zrbzCKwfhMSQFS5bhGgMlilAvnEvA7XH5wlQn4f9KsvYjRcj8bhcu/S0eFd8xVRdLHe4 AaprafJ9PvLr3v2T9he8dvjb+NsuHQ7vIf7LPLo0opxVpQMoo1vRh+7hr9NL+SfRbE6P 6NeA== MIME-Version: 1.0 X-Received: by 10.224.66.74 with SMTP id m10mr4872730qai.12.1378481102188; Fri, 06 Sep 2013 08:25:02 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Fri, 6 Sep 2013 08:25:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 6 Sep 2013 10:25:02 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c2c3386cf85804e5b8a4fa Subject: Re: [clue] Revised IETF-87 Minutes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2013 15:25:17 -0000 --001a11c2c3386cf85804e5b8a4fa Content-Type: text/plain; charset=ISO-8859-1 This is a reminder that folks really need to review these minutes. They include summaries of the discussions as well as action items. And, of course, for folks that weren't at the meeting that want to understand what was discussed in more detail, the Meetcho recording is invaluable for that. The absolute, final deadline for any updates to these minutes is Sept. 18th: https://datatracker.ietf.org/meeting/87/materials.html However, the chairs are asking for any comments to be made no later than Sept. 11th to allow us time to sort through any concerns. Regards, Mary. On Thu, Aug 22, 2013 at 5:27 PM, Mary Barnes wrote: > I have uploaded a revised version of the minutes that includes a summary > with conclusions/action items: > http://www.ietf.org/proceedings/87/minutes/minutes-87-clue > > If you have previously looked at the minutes you may need to refresh your > browser to see the revised version. > > Please review and provide any comments or questions no later than August > 30th, 2013. Note that there is a link to the Meetecho recording in the > minutes - that is very helpful for remembering the discussions. > > Regards, > Mary. > --001a11c2c3386cf85804e5b8a4fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is a reminder that folks really need to review these = minutes. They include summaries of the discussions as well as action items.= =A0And, of course, for folks that weren't at the meeting that want to = understand what was discussed in more detail, the Meetcho recording is inva= luable for that.

The absolute, final deadline for any updates to these minute= s is Sept. 18th: https://datatracker.ietf.org/meeting/87/materials.html
However, the chairs are asking for any comments to be made no later th= an Sept. 11th to allow us time to sort through any concerns.

=
Regards,
Mary.=A0


On Thu, Aug 22, 2013 at 5:27 PM, Mary Barnes= <mary.ietf.barnes@gmail.com> wrote:
I have uploaded a revised version of the minutes that incl= udes a summary with conclusions/action items:

If you have previously looked at the minutes you may ne= ed to refresh your browser to see the revised version.

Please review and provide any comments or questions no later than = August 30th, 2013. =A0 Note that there is a link to the Meetecho recording = in the minutes - that is very helpful for remembering the discussions.

Regards,
Mary.=A0

--001a11c2c3386cf85804e5b8a4fa-- From internet-drafts@ietf.org Sat Sep 7 01:03:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4087C21F86BE; Sat, 7 Sep 2013 01:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+QxgzV7hgiV; Sat, 7 Sep 2013 01:03:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AFD21F864D; Sat, 7 Sep 2013 01:03:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130907080326.28109.53331.idtracker@ietfa.amsl.com> Date: Sat, 07 Sep 2013 01:03:26 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-use-cases-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 08:03:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Use Cases for Telepresence Multi-streams Author(s) : Allyn Romanow Stephen Botzko Mark Duckworth Roni Even Filename : draft-ietf-clue-telepresence-use-cases-07.txt Pages : 17 Date : 2013-09-07 Abstract: Telepresence conferencing systems seek to create an environment that gives non co-located users or user groups a feeling of co-located presence through multimedia communication including at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-use-cases-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-use-cases-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Sat Sep 7 01:12:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B6E11E80F1 for ; Sat, 7 Sep 2013 01:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3++pmW-nW7C for ; Sat, 7 Sep 2013 01:12:45 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7321B11E80D3 for ; Sat, 7 Sep 2013 01:12:44 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so1328649wgh.27 for ; Sat, 07 Sep 2013 01:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=IteFrBEOaIX3xrYEr1TIn6+d86ZPKoxfHyqmQuAOLE0=; b=CMXe66kvXFMZh8N3eQ51bPp0WkzXvRWcSxtYiYj91TUYfjOdu3X+AUTtWXabc+Xl6u 3w/h34FADKQqRI9LOJWKH9hlu6/c89Mb/mrT9LJt2i0PAKc8wbFrhRRsNKtYmEKRRh1L +WaL5+v7mkisIRHq4fp6UyUQv9qRrdUcQ0S6Bfpm7277VRABnC2hZea0Vo42kob8YhXC PHjsolrBjpE3R95zliSemY7cLRLlwJ+PQw9kpqPPH2Xk1nX52VCx+tM3TRwFn0mXYZg1 PMtozM3VpwGt4EsN23oRWtNOsLpik5d1RcGpNqQvnG78qSoMWSrjRW4iu23axjvBp0ii Piiw== X-Received: by 10.194.241.228 with SMTP id wl4mr5380136wjc.2.1378541563480; Sat, 07 Sep 2013 01:12:43 -0700 (PDT) Received: from RoniE (bzq-79-181-232-77.red.bezeqint.net. [79.181.232.77]) by mx.google.com with ESMTPSA id d11sm1941713wic.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 07 Sep 2013 01:12:43 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Sat, 7 Sep 2013 11:10:02 +0300 Message-ID: <057701ceaba1$a960a290$fc21e7b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0578_01CEABBA.CEAF3A20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3dWs4erzQY5QLLb9yNsglWNAwqZpoV7gA Content-Language: en-us Cc: 'Roni Even' Subject: Re: [clue] Preparing PROTO Write-up for Use case document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2013 08:12:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0578_01CEABBA.CEAF3A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I submitted 07 version including the comment and nits. I have problem with removing the following text from section 3.4 so I am asking for more feedback. "In H.323[ITU.H323] systems, H.239[ITU.H239] is typically used to control the video presentation stream. In SIP systems, similar control mechanisms can be provided using BFCP [RFC4582] for presentation token. These mechanisms are suitable for managing a single presentation stream." My view is that using H.239 is the current use case for presentation. Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 03 September, 2013 6:07 PM To: CLUE Cc: Roni Even Subject: [clue] Preparing PROTO Write-up for Use case document Hi all, In the process of re-reviewing the use cases document in preparation of the PROTO write-up, I came across the following nits and a couple minor issues that I would like to discuss with the WG. Thanks, Mary. Minor issues: ------------------- - Section 2, first two paragraphs after numbered list. I struggled a little bit with this text (which is more of a problem statement) in a section that's providing an overview of scenarios. I would suggest to move the first of those two paragraphs into section 1 and delete that 2nd paragraph (in section 2) as I think what's important is the current last sentence of the 2nd paragraph in section 1. Thus, I'm suggesting changing the 2nd paragraph in section 1 as follows: OLD: Although telepresence systems are based on open standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor's protocol to another. A standard way of describing the multiple streams constituting the media flows and the fundamental aspects of their behavior, would allow telepresence systems to interwork. NEW: Although telepresence systems are based on open standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they cannot easily interoperate with each other without operator assistance and expensive additional equipment which translates from one vendor's protocol to another. The basic features that give telepresence its distinctive characteristics are implemented in disparate ways in different systems. Currently Telepresence systems from diverse vendors interoperate to some extent, but this is not supported in a standards based fashion. Interworking requires that translation and transcoding devices be included in the architecture. Such devices increase latency, reducing the quality of interpersonal interaction. Use of these devices is often not automatic; it frequently requires substantial manual configuration and a detailed understanding of the nature of underlying audio and video streams. This state of affairs is not acceptable for the continued growth of telepresence - telepresence systems should have the same ease of interoperability as do telephones. Thus, a standard way of describing the multiple streams constituting the media flows and the fundamental aspects of their behavior, would allow telepresence systems to interwork. - Section 3.4, 5th paragraph : This seems misplaced as there isn't anywhere else in the document where we talk about protocols (this is something which would really be more appropriately discussed in the solution documents). I would suggest to delete this paragraph. Nits: ------- - Section 1, 3rd paragraph, 1st sentence: "draft"->"document", "requirements will be derived" -> "requirements are derived" - Section 1, last paragraph: Need to add two spaces after "This document structure is as follows:" - Section 2, "users we will call participant cameras" -> "users are referred to as participant cameras" (consistent with wording a couple sentences down) - Section 3, first sentence. Adding spacing after the sentence. - Section 3.7, first paragraph, 1st sentence. Adding spacing after the sentence. - Section 3.9, first paragraph, last sentence. This is awkwardly worded. I suggest changing: "assist the process of the surgery" to simply "assist in the surgery" or "assist in the surgical process" - Section 4. 1st para. "draft" -> "document" ------=_NextPart_000_0578_01CEABBA.CEAF3A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I = submitted 07 version including the comment and = nits.

I have = problem with removing the following text from section 3.4 so I am asking = for more feedback.

 =

“In = H.323[ITU.H323] systems, H.239[ITU.H239] is typically used = to

  = ; control the video presentation stream.  In SIP systems, = similar

  = ; control mechanisms can be provided using BFCP [RFC4582] = for

  = ; presentation token.  These mechanisms are suitable for managing = a

  = ; single presentation stream.”

 =

My view is = that  using H.239 is the current  use case for presentation. =

Roni

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 03 September, 2013 6:07 PM
To: = CLUE
Cc: Roni Even
Subject: [clue] Preparing PROTO = Write-up for Use case document

 

Hi = all,

 

In the process of re-reviewing the use cases document = in preparation of the PROTO write-up, I came across the following nits = and a couple minor issues that I would like to discuss with the = WG. 

 

Thanks,

Mary.

 

Minor issues:

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

 

- = Section 2, first two paragraphs after numbered list.  I struggled a = little bit with this text (which is more of a problem statement) in a = section that's providing an overview of scenarios. I would suggest to = move the first of those two paragraphs into section 1 and delete that = 2nd paragraph (in section 2)  as I think what's important is the = current last sentence of the 2nd paragraph in section 1.  Thus, I'm = suggesting changing the 2nd paragraph in section 1 as = follows:

OLD:

Although telepresence systems are based on open = standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the = H.323[ITU.H323] suite of protocols, they cannot easily interoperate with = each other without operator assistance and expensive additional = equipment which translates from one vendor's protocol to another. A = standard way of describing the multiple streams constituting the media = flows and the fundamental aspects of their behavior, would allow = telepresence systems to = interwork.

 

NEW: 

Although telepresence systems are based on open = standards such as RTP[RFC3550], SIP [RFC3261], H.264, and the = H.323[ITU.H323] suite of protocols, they cannot easily interoperate with = each other without operator assistance and expensive additional = equipment which translates from one vendor's protocol to = another. 

The = basic features that give telepresence its distinctive = characteristics are implemented in disparate ways in = different = systems. Currently Telepresence systems from diverse = vendors = interoperate to some extent, but this is not supported = in a standards = based = fashion. Interworking requires that translation and = transcoding devices be included in the architecture. = Such devices = increase latency, reducing the quality of = interpersonal interaction. = Use of = these devices is often not automatic; it frequently = requires = substantial manual configuration and a detailed = understanding of the = nature = of underlying audio and video streams. This state of = affairs = is not = acceptable for the continued growth of telepresence - = telepresence systems should have the same ease of = interoperability as = do = telephones. Thus, a standard way of describing the multiple streams = constituting the media flows and the fundamental aspects of their = behavior, would allow telepresence systems to = interwork.

 

- = Section 3.4, 5th paragraph :  This seems misplaced as there isn't = anywhere else in the document where we talk about protocols (this is = something which would really be more appropriately discussed in the = solution documents).  I would suggest to delete this paragraph. =  

 

Nits:

-------

- Section 1, 3rd paragraph, 1st sentence: = "draft"->"document", "requirements will be = derived" -> "requirements are = derived"

- Section 1, = last paragraph: Need to add two spaces after "This document = structure is as follows:"   

- Section 2, "users we will call participant = cameras" -> "users are referred to as participant = cameras"  (consistent with wording a couple sentences = down) 

- Section 3, = first sentence.  Adding spacing after the = sentence. 

- Section = 3.7, first paragraph, 1st sentence.  Adding spacing after the = sentence.

- Section 3.9, = first paragraph, last sentence.  This is awkwardly worded. I = suggest changing: "assist the process of the surgery" to = simply "assist in the surgery" or "assist in the surgical = process" 

- = Section 4.  1st para. "draft" -> = "document"

------=_NextPart_000_0578_01CEABBA.CEAF3A20-- From Christian.Groves@nteczone.com Mon Sep 9 03:35:53 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAF221E815E for ; Mon, 9 Sep 2013 03:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCga+R07rpKQ for ; Mon, 9 Sep 2013 03:35:46 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF7A21E8160 for ; Mon, 9 Sep 2013 03:35:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMBALGjLVJ20ctK/2dsb2JhbAANToM/xBxtgmsbFRA9FhgDAgECAUsNCAEBiAqySpIIlCQDmSSTaQ Received: from ppp118-209-203-74.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.203.74]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Sep 2013 20:05:34 +0930 Message-ID: <522DA473.7010506@nteczone.com> Date: Mon, 09 Sep 2013 20:35:31 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Roles - Conference System Control Role X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 10:35:53 -0000 Hello To follow up on my draft > on roles I'm proposing some text for the framework for 3 new attributes to stimulate some discussion. I'll keep each of the attributes in a separate thread as there may be different issues for each attribute. My proposed text to add to the framework for conference system control role is: In 6.1.1 Media Capture Attributes: Conference System Control Role: This attribute indicates that the person depicted in the media capture has certain conference control responsibilities. It does not provide any authorisation in a conference management system for these conference control roles. The information is provided as a means for the consumer to select media captures and for display/playout purposes. The conference system control roles attribute has the following values: Presenter Indicates a person that can share content/media with others. May also be known as speaker. Controller Indicates the person responsible for controlling admission to the conference. Sets up the meeting, adds and shares contents, control who presents and talks. Also known as "host". Participant Indicates a participant in the conference who does not have any special control. Receives media and content from presenter. Unlike meeting role a person can only have one conference system control role at a time. However as multiple people can be captured in a media capture the conference system control role may have multiple values. Comments? Regards, Christian From Christian.Groves@nteczone.com Mon Sep 9 03:35:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7305E21E816C for ; Mon, 9 Sep 2013 03:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huELMbT+89wy for ; Mon, 9 Sep 2013 03:35:50 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id CB3EC21E8165 for ; Mon, 9 Sep 2013 03:35:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMBALGjLVJ20ctK/2dsb2JhbAANToM/xBxtgmsbJT0WGAMCAQIBSw0IAQGICrJKkgiUJAOZJJNp Received: from ppp118-209-203-74.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.203.74]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Sep 2013 20:05:30 +0930 Message-ID: <522DA46E.9050506@nteczone.com> Date: Mon, 09 Sep 2013 20:35:26 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Roles - Meeting Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 10:35:58 -0000 Hello To follow up on my draft > on roles I'm proposing some text for the framework for 3 new attributes to stimulate some discussion. I'll keep each of the attributes in a separate thread as there may be different issues for each attribute. My proposed text to add to the framework for meeting roles is: In 6.1.1 Media Capture Attributes: Meeting Role: This attribute indicates the meeting role of the participant/s in the capture. The meeting role relates to the function the participant/s have with respect to running the meeting. As a media capture may capture more than one person the attribute more than one value per media capture. A person may also have more than one meeting role, i.e. a secretary and time keeper. Multiple people within a capture may also have the same role, i.e. three people in a capture may all be participants. In such a case a meeting role attribute would only need a single value "participant". The meeting role attribute has the following meeting roles: Chairman A person who convenes the meeting and presides over discussions. Also known as a moderator or rapporteur. ViceChairman A person who assist the chairman. Secretary A person who is responsible for documenting the meeting. Also known as a scribe, recorder or minute taker. Participant A person who is participating in a meeting that has no other role in a meeting. Also known as a member, participant or audience. Presenter A person who has been invited to present a message to the meeting. Also known as a lecturer. Translator A person who translates from one language to another in a meeting. Timekeeper A person who is responsible who records the time taken for the meeting. In addition this attribute supports a text field to allow an endpoint to provide a user defined meeting role. Comments? Regards, Christian From Christian.Groves@nteczone.com Mon Sep 9 03:36:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7C521E8134 for ; Mon, 9 Sep 2013 03:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl-w6sHhyQDP for ; Mon, 9 Sep 2013 03:35:58 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id EA5CF21E8151 for ; Mon, 9 Sep 2013 03:35:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMBALGjLVJ20ctK/2dsb2JhbAANToM/xBxtgmUBBRsVED0WGAMCAQIBSw0IAQGICrJKkgiUJAOZJJNp Received: from ppp118-209-203-74.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.203.74]) by ipmail04.adl6.internode.on.net with ESMTP; 09 Sep 2013 20:05:38 +0930 Message-ID: <522DA477.8000109@nteczone.com> Date: Mon, 09 Sep 2013 20:35:35 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [clue] Roles - Capture and Scene vCard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 10:36:06 -0000 Hello To follow up on my draft > on roles I'm proposing some text for the framework for 3 new attributes to stimulate some discussion. I'll keep each of the attributes in a separate thread as there may be different issues for each attribute. My proposed text to add to the framework for vCard information is: In 6.1.1 Media Capture Attributes: Capture vCard: This attribute allows vCard [RFC6350] description/s to be associated with a capture. VCard defines a data format for representing and exchanging a variety of information about individuals and other entities. The information is grouped into the following set of properties: o Identification Properties o Delivery addressing properties o Communications Properties o Organizational Properties o Explanatory Properties o Security Properties o Calendar Properties These properties allow information such a participant’s “Person Name Title”, “Person Occupation” and “Organisation Name”. Whilst vCard allows to send a large amount of information an advertiser may choose to send a minimal set of information such as only a name or a more complete set with personal title, job title etc. The only mandatory vCard field (apart from syntax related ones) is the "FN" (Formatted name) property (section 6.2.1/[RFC 6350]). This relates to the vCard "object" rather than a "person" which allows for names other than person names to be used. So an endpoint could transit the meeting roles even if the names of the people in the conference are not available. Advertisers utilising the vCard “role” parameter (section 6.6.2/[RFC6350]) SHOULD consider the use of ISO codes for the classifications of occupation defined by [ISCO-8] “International Standard Classification of Occupations”. The supported values and syntax of the attribute are as per [RFC 6350] Alternatively an URI can be provided to point to a vCard description. {CNG Note: Whilst this would keep message size down it does potentially introduce security issues if the receiver is told to access a remote site. Not sure about this? Opinions? } AND in 6.2.1 Capture Scene Attributes . vCard description of the Scene containing a a "group", "org" or "location" kind of vCard according to section 6.1.4/[RFC6350] to be associated with a capture. Comments? Regards, Christian From keith.drage@alcatel-lucent.com Mon Sep 9 04:24:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F059221E8181 for ; Mon, 9 Sep 2013 04:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q16EVbmmGqgT for ; Mon, 9 Sep 2013 04:24:07 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 816D321E816A for ; Mon, 9 Sep 2013 04:24:07 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r89BO4Gi002769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Sep 2013 06:24:05 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r89BNxWB032424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 13:24:03 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 9 Sep 2013 13:24:00 +0200 From: "DRAGE, Keith (Keith)" To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Roles - Meeting Roles Thread-Index: AQHOrUhtAIzDikkNHUCmduXj3D9Y5Zm9Qk9w Date: Mon, 9 Sep 2013 11:23:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B09F5E3@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <522DA46E.9050506@nteczone.com> In-Reply-To: <522DA46E.9050506@nteczone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [clue] Roles - Meeting Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 11:24:20 -0000 Do we need the role of vice chairman. The normal definition of vice chairman (I agree not the one given here) is = one who substitutes for the chairman in their absence) which effectively me= ans they become the chairman. Any of the other roles could be an assistant to the chairman, so unless we = agree what the measure of that assistance is - then we have no idea what th= at role is. As stated any of these roles can be duplicated, so we could have multiple c= hairmen. Conversely (and not something I am proposing), if we are introducing the id= ea of a hierarchy within a role, then that could be applied to other roles = as well, e.g. chief secretary, second secretary, third secretary. Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 09 September 2013 11:35 > To: clue@ietf.org > Subject: [clue] Roles - Meeting Roles >=20 > Hello >=20 > To follow up on my draft > > on > roles I'm proposing some text for the framework for 3 new attributes to > stimulate some discussion. I'll keep each of the attributes in a > separate thread as there may be different issues for each attribute. >=20 > My proposed text to add to the framework for meeting roles is: >=20 > In 6.1.1 Media Capture Attributes: >=20 > Meeting Role: >=20 > This attribute indicates the meeting role of the participant/s in the > capture. The meeting role relates to the function the participant/s > have > with respect to running the meeting. As a media capture may capture > more > than one person the attribute more than one value per media capture. > A > person may also have more than one meeting role, i.e. a secretary and > time keeper. Multiple people within a capture may also have the same > role, i.e. three people in a capture may all be participants. In > such a case a meeting role attribute would only need a single value > "participant". >=20 > The meeting role attribute has the following meeting roles: >=20 > Chairman A person who convenes the meeting and presides over > discussions. Also known as a moderator or > rapporteur. >=20 > ViceChairman A person who assist the chairman. >=20 > Secretary A person who is responsible for documenting the > meeting. Also known as a scribe, recorder or minute > taker. >=20 > Participant A person who is participating in a meeting that has > no other role in a meeting. Also known as a member, > participant or audience. >=20 > Presenter A person who has been invited to present a message to > the meeting. Also known as a lecturer. >=20 > Translator A person who translates from one language to another > in a meeting. >=20 > Timekeeper A person who is responsible who records the time > taken for the meeting. >=20 > In addition this attribute supports a text field to allow an endpoint > to provide a user defined meeting role. >=20 > Comments? >=20 > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Mon Sep 9 07:29:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C78911E81E0 for ; Mon, 9 Sep 2013 07:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5thWmiQYmd8 for ; Mon, 9 Sep 2013 07:29:04 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 0D54E21E818F for ; Mon, 9 Sep 2013 07:18:45 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id NzEG1m0030cZkys5D2JlWK; Mon, 09 Sep 2013 14:18:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([IPv6:2002:328a:e5a4:0:4c49:9185:3ff8:da49]) by omta10.westchester.pa.mail.comcast.net with comcast id P2JC1m00v4l4JME3W2JD32; Mon, 09 Sep 2013 14:18:45 +0000 Message-ID: <522DD8A0.402@alum.mit.edu> Date: Mon, 09 Sep 2013 10:18:08 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE References: <1066539601.49380.1378217600179.JavaMail.nobody@jva2tc113.webex.com> In-Reply-To: <1066539601.49380.1378217600179.JavaMail.nobody@jva2tc113.webex.com> X-Forwarded-Message-Id: <1066539601.49380.1378217600179.JavaMail.nobody@jva2tc113.webex.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378736325; bh=COin2GvdVtLvZDDFJuNz2iCVutqr5Pxbgf+BeKrvXXQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K28fMmmtKFx4zUyKen893DzxXark1hbaiXpuBkXcMCrtktDcTDZk/zwjPgMyNZoYd LTDZJ/OxMHWmHOXTmcvsmdY/svqGzCR9kzTGT/OcLEWs2710+alxi+6MbftIjmTn5w VXxBfjtFIjJPn++Wojpv4XxPUDppu8/1916CMeE+zW9PQz4h6I/j7FmChSOg9Ars+b jdIwSgF1fJM9F9eIR9s3fo46Oa6IZNxBh2pHiJXQ+2/bh3TYng7tOAy8iYI8A5nHgj NWl1U+sx/OmY5s1IEIk6OA4MaBKgihI9+XwTuQ1YayjfSwmrGcLuVAMwstUErRXemA qEu+L5hqYnRTg== Subject: [clue] REMINDER: CLUE WG Signaling Design Team, tomorrow, Tuesday 10-sep X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 14:29:15 -0000 The first of the new series of design team meetings will be Tuesday Sept 10. (See below for time.) The new series is concentrating on the CLUE signaling. This meeting is open to all who are willing to contribute. Contribute means that you volunteer to provide text. We have a set of volunteers, and they are the people I expect to have call in: Simon, Roberta, Christer, Rob, Roni, and maybe Jonathan. (Others willing to contribute are welcome. If you'd like to join, please contact me so we can discuss your role.) For this first session I've promised to take the lead on the issue of: Approach to versioning/options/extensions. I won't have text in the draft for this by then, but I will have a specific proposal, in PPT form. Thanks, Paul -------- Original Message -------- Subject: (Forward to attendees) Meeting invitation: CLUE WG Signaling Design Team Resent-Date: Tue, 3 Sep 2013 10:13:33 -0400 Resent-From: wg-alias-bounces@tools.ietf.org Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu Date: Tue, 3 Sep 2013 14:13:20 +0000 (GMT) From: Clue Working Group Reply-To: clue-chairs@tools.ietf.org To: clue-chairs@tools.ietf.org **** You can forward this email invitation to attendees **** Hello , Clue Working Group invites you to attend this online meeting. Topic: CLUE WG Signaling Design Team Date: Tuesday, September 10, 2013 Time: 8:30 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 646 255 438 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:646 255 438 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAs4wxodSid4H6UBgrF-kJ6kSpPUMhaRJyeYRYM3ZPM23&RT=MiM3 The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x646255438# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From jonathan@vidyo.com Mon Sep 9 12:38:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C5F21E816E for ; Mon, 9 Sep 2013 12:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd0JAkH-d61o for ; Mon, 9 Sep 2013 12:37:57 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7804921E8159 for ; Mon, 9 Sep 2013 12:37:52 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C350C554EEA; Mon, 9 Sep 2013 15:37:51 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F319B554CDE; Mon, 9 Sep 2013 15:37:50 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 9 Sep 2013 15:35:03 -0400 From: Jonathan Lennox To: Christian Groves Date: Mon, 9 Sep 2013 15:37:49 -0400 Thread-Topic: [clue] Roles - Conference System Control Role Thread-Index: Ac6tk63VTtWhaY3VTAiLLjdXXzUyoQ== Message-ID: <98A86F5F-5DEA-4646-9DF0-C99FEA290AD2@vidyo.com> References: <522DA473.7010506@nteczone.com> In-Reply-To: <522DA473.7010506@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] Roles - Conference System Control Role X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 19:38:02 -0000 Hi, Christian -- What I'm trying to understand (for all three of your proposed role attribut= es) is the use cases in which they'd be used. Are they intended for automa= tic (machine) consumption, or human? As I mentioned in the face-to-face meeting, why should these be part of CLU= E, as opposed to XCON or something similar as part of the meeting roster in= formation? What should endpoints do in circumstances where the role types are entirely= unlike the classic corporate-meeting model, e.g. our doctor's-surgery use = case? Are there any existing conferencing or telepresence systems that carry this= sort of information, and how is it used in the system? On Sep 9, 2013, at 6:35 AM, Christian Groves wrote: > Hello >=20 > To follow up on my draft >= on=20 > roles I'm proposing some text for the framework for 3 new attributes to=20 > stimulate some discussion. I'll keep each of the attributes in a=20 > separate thread as there may be different issues for each attribute. >=20 > My proposed text to add to the framework for conference system control=20 > role is: >=20 > In 6.1.1 Media Capture Attributes: >=20 > Conference System Control Role: >=20 > This attribute indicates that the person depicted in the media capture=20 > has certain conference control responsibilities. It does not provide any= =20 > authorisation in a conference management system for these conference=20 > control roles. The information is provided as a means for the consumer=20 > to select media captures and for display/playout purposes. >=20 > The conference system control roles attribute has the following values: >=20 > Presenter Indicates a person that can share content/media with > others. May also be known as speaker. >=20 > Controller Indicates the person responsible for controlling > admission to the conference. Sets up the meeting, > adds and shares contents, control who presents and > talks. Also known as "host". >=20 > Participant Indicates a participant in the conference who does > not have any special control. Receives media and > content from presenter. >=20 > Unlike meeting role a person can only have one conference system > control role at a time. However as multiple people can be captured > in a media capture the conference system control role may have > multiple values. >=20 > Comments? >=20 > Regards, Christian >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 -- Jonathan Lennox jonathan@vidyo.com From pkyzivat@alum.mit.edu Mon Sep 9 12:58:22 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D0F11E8128 for ; Mon, 9 Sep 2013 12:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoyreP2nQmVW for ; Mon, 9 Sep 2013 12:58:17 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 99AF711E8131 for ; Mon, 9 Sep 2013 12:58:13 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id Nzax1m0021HzFnQ5E7yCgU; Mon, 09 Sep 2013 19:58:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id P7yC1m00d3ZTu2S3a7yCCz; Mon, 09 Sep 2013 19:58:12 +0000 Message-ID: <522E2853.9020903@alum.mit.edu> Date: Mon, 09 Sep 2013 15:58:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <522DA473.7010506@nteczone.com> In-Reply-To: <522DA473.7010506@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378756692; bh=S/zQSUSAVSJhLqmOTGKeUxEBgwbBjKEedrWMSsU9yiU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Q2MJvD1Ckc6Gy48Qpw68XKZeRWB2UclwHqU43Yp+Yq1cnnpKxfrKjXjrP2zU4LjwG RWeIpr88d+FnLbhk2Ge+S37bNaLPk3c8glNKeVNgFUsv+bgBTjL+o2qcZfHKAfD28f YDq770Aq8VvPH+v7eL/kJO/ZFhaqHSZU6EpNwRgjqWcBFDwiYxgciwUFVWbFiCBSKc A2JSC1XV3Dd0WNrWbN40QABF/9gl9mGN13UYQuBrD7O5hBZ4Pd+dZuVhuz5bT1AbMI u5YhTKMjbzSYbawDivb2OL3HhvIvZ5sjEWtsnF4jSQhtGLtfHbSFgX9euwnS2J5W8+ ocUaWN7d4Vctw== Subject: Re: [clue] Roles - Conference System Control Role X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 19:58:25 -0000 Christian, Regarding Presenter and Participant, I'm confused about how you see them being used in different types of conferences: - in our traditional TP conference, with several "rooms" that operate as peers, are all of them Presenters? Speakers? Both? - in a conference like the above, but where we also have floor control over a presentation capture, does the Presenter role move around with the floor assignment? If so, who changes it? Must the endpoint getting the floor do it? Or the focus? Thanks, Paul On 9/9/13 6:35 AM, Christian Groves wrote: > Hello > > To follow up on my draft > on > roles I'm proposing some text for the framework for 3 new attributes to > stimulate some discussion. I'll keep each of the attributes in a > separate thread as there may be different issues for each attribute. > > My proposed text to add to the framework for conference system control > role is: > > In 6.1.1 Media Capture Attributes: > > Conference System Control Role: > > This attribute indicates that the person depicted in the media capture > has certain conference control responsibilities. It does not provide any > authorisation in a conference management system for these conference > control roles. The information is provided as a means for the consumer > to select media captures and for display/playout purposes. > > The conference system control roles attribute has the following values: > > Presenter Indicates a person that can share content/media with > others. May also be known as speaker. > > Controller Indicates the person responsible for controlling > admission to the conference. Sets up the meeting, > adds and shares contents, control who presents and > talks. Also known as "host". > > Participant Indicates a participant in the conference who does > not have any special control. Receives media and > content from presenter. > > Unlike meeting role a person can only have one conference system > control role at a time. However as multiple people can be captured > in a media capture the conference system control role may have > multiple values. > > Comments? > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Sep 9 15:11:24 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137D711E80F1 for ; Mon, 9 Sep 2013 15:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLedOtd+vZ-d for ; Mon, 9 Sep 2013 15:11:19 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 44D5211E8122 for ; Mon, 9 Sep 2013 15:11:19 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta10.westchester.pa.mail.comcast.net with comcast id P2Gv1m00B1swQuc5AABGDY; Mon, 09 Sep 2013 22:11:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id PABF1m00a3ZTu2S3bABFLY; Mon, 09 Sep 2013 22:11:16 +0000 Message-ID: <522E4782.5010600@alum.mit.edu> Date: Mon, 09 Sep 2013 18:11:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <1066539601.49380.1378217600179.JavaMail.nobody@jva2tc113.webex.com> <522DD8A0.402@alum.mit.edu> In-Reply-To: <522DD8A0.402@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378764676; bh=LMeU0Fuv1rJM1MK6rSVkyA6K0R0s+KRT+dZ7Qs1gzW8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dUTUSU9mlgXOgH7E4yE5b386ZIVMJz40BfV6MCN5AKCdDNL91GH3hrofe8/riSeFR UaJoDaDjQv70tQQQeZiU1PmVmwL18kjOj32NpLDa9B83Ufsh00DxXR0aBaDwkzi4/m EeCI8TsPSn2ddW6Qx5rXZeX01ititEVnhDECI6JuvXsg6HlBA6kGx+QTqaL6ayWByj MKZpU0K1rKGn2S07giNLLWsJuth1gjKBiq5JZCdTaW00746WpxMh5gPUEDlvN/uMdI fQ925i1E/x4W65onx+yMBY4+TDkLkjbwZjQ1C3WYh4n2u+mKopAddFrbA+J9ELoYTA L1h+Kc4str+lA== Subject: Re: [clue] REMINDER: CLUE WG Signaling Design Team, tomorrow, Tuesday 10-sep X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 22:11:24 -0000 I put the ppt I will be using tomorrow on the wiki. You can pull it directly from: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/CLUE%20versioning.10sep13.pptx Thanks, Paul On 9/9/13 10:18 AM, Paul Kyzivat wrote: > The first of the new series of design team meetings will be Tuesday Sept > 10. > (See below for time.) > > The new series is concentrating on the CLUE signaling. > This meeting is open to all who are willing to contribute. > Contribute means that you volunteer to provide text. > > We have a set of volunteers, and they are the people I expect to have > call in: > Simon, Roberta, Christer, Rob, Roni, and maybe Jonathan. > (Others willing to contribute are welcome. If you'd like to join, please > contact me so we can discuss your role.) > > For this first session I've promised to take the lead on the issue of: > Approach to versioning/options/extensions. > I won't have text in the draft for this by then, but I will have a > specific proposal, in PPT form. > > Thanks, > Paul > > -------- Original Message -------- > Subject: (Forward to attendees) Meeting invitation: CLUE WG Signaling > Design Team > Resent-Date: Tue, 3 Sep 2013 10:13:33 -0400 > Resent-From: wg-alias-bounces@tools.ietf.org > Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu > Date: Tue, 3 Sep 2013 14:13:20 +0000 (GMT) > From: Clue Working Group > Reply-To: clue-chairs@tools.ietf.org > To: clue-chairs@tools.ietf.org > > > > > **** You can forward this email invitation to attendees **** > > Hello , > > Clue Working Group invites you to attend this online meeting. > > Topic: CLUE WG Signaling Design Team > Date: Tuesday, September 10, 2013 > Time: 8:30 am, Central Daylight Time (Chicago, GMT-05:00) > Meeting Number: 646 255 438 > Meeting Password: 1234 > > > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&RT=MiM3 > > > 2. If requested, enter your name and email address. > 3. If a password is required, enter the meeting password: 1234 > 4. Click "Join". > > To view in other time zones or languages, please click the link: > https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&ORT=MiM3 > > > > ------------------------------------------------------- > To join the audio conference only > ------------------------------------------------------- > Call-in toll number (US/Canada): 1-650-479-3208 > > Access code:646 255 438 > > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://ietf.webex.com/ietf/mc > 2. On the left navigation bar, click "Support". > > You can contact me at: > clue-chairs@tools.ietf.org > > > To add this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAs4wxodSid4H6UBgrF-kJ6kSpPUMhaRJyeYRYM3ZPM23&RT=MiM3 > > > > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in > the meeting, please check whether you have the players installed on your > computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. > > Sign up for a free trial of WebEx > http://www.webex.com/go/mcemfreetrial > > http://www.webex.com > > CCP:+16504793208x646255438# > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Sep 9 15:57:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A2121E80DB for ; Mon, 9 Sep 2013 15:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.183 X-Spam-Level: X-Spam-Status: No, score=-102.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zY8we7fa2EHC for ; Mon, 9 Sep 2013 15:57:50 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8B19321E80D6 for ; Mon, 9 Sep 2013 15:57:50 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id nd7so2755128qeb.21 for ; Mon, 09 Sep 2013 15:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zl3eTG4gFNp7ZwS9jxO3FLuyCspmUMAOUS1ZKuJhkV8=; b=guOYQUYnyiIgdy0fA1jVWRtwsQndLP4ye2bxpJBTd9sNBoSwoYC/N/3X/dUQcK0RFL J1pskXRIsUCSu+ZFbH2JW+9v9KrG34tlZqpDJvNb3Zn347iiZAvhwW6VBmRQnivj2WDT YtEVz3UdJgXypzddUJP0VHeA1Upn39jbOT1qaSpqk5AgUD6SC/tBrvEqnZHTmcEiMaTV zvF5+wzkJRlscCURCM03sT2nC0rg06IBQmmfn5iBAtKCrYNwWnRQe3DZRSGsLu/rFjHc fEffq65x7gsAMW4HJy5i0RN+0paydZd7dTxBiw/1qc5lCbRb0EnPzpCXHJxGuOyL/eTm HC7w== MIME-Version: 1.0 X-Received: by 10.224.50.71 with SMTP id y7mr4445974qaf.62.1378767469950; Mon, 09 Sep 2013 15:57:49 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Mon, 9 Sep 2013 15:57:49 -0700 (PDT) In-Reply-To: <057701ceaba1$a960a290$fc21e7b0$@gmail.com> References: <057701ceaba1$a960a290$fc21e7b0$@gmail.com> Date: Mon, 9 Sep 2013 17:57:49 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=047d7bf0e14e463b6f04e5fb516c Cc: Roni Even , CLUE Subject: Re: [clue] Preparing PROTO Write-up for Use case document X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 22:57:52 -0000 --047d7bf0e14e463b6f04e5fb516c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Roni. I have reviewed the updated version and will retract my comment with regards to the H.239 reference. I will submit the PROTO write-up as soon as I have responses from all the authors with regards to IPR. Thanks, Mary. On Sat, Sep 7, 2013 at 3:10 AM, Roni Even wrote: > Hi,**** > > I submitted 07 version including the comment and nits.**** > > I have problem with removing the following text from section 3.4 so I am > asking for more feedback.**** > > ** ** > > =93In H.323[ITU.H323] systems, H.239[ITU.H239] is typically used to**** > > control the video presentation stream. In SIP systems, similar**** > > control mechanisms can be provided using BFCP [RFC4582] for**** > > presentation token. These mechanisms are suitable for managing a**** > > single presentation stream.=94**** > > ** ** > > My view is that using H.239 is the current use case for presentation. *= * > ** > > Roni**** > > ** ** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 03 September, 2013 6:07 PM > *To:* CLUE > *Cc:* Roni Even > *Subject:* [clue] Preparing PROTO Write-up for Use case document**** > > ** ** > > Hi all,**** > > ** ** > > In the process of re-reviewing the use cases document in preparation of > the PROTO write-up, I came across the following nits and a couple minor > issues that I would like to discuss with the WG. **** > > ** ** > > Thanks,**** > > Mary.**** > > ** ** > > Minor issues:**** > > -------------------**** > > ** ** > > - Section 2, first two paragraphs after numbered list. I struggled a > little bit with this text (which is more of a problem statement) in a > section that's providing an overview of scenarios. I would suggest to mov= e > the first of those two paragraphs into section 1 and delete that 2nd > paragraph (in section 2) as I think what's important is the current last > sentence of the 2nd paragraph in section 1. Thus, I'm suggesting changin= g > the 2nd paragraph in section 1 as follows:**** > > OLD:**** > > Although telepresence systems are based on open standards such as > RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of > protocols, they cannot easily interoperate with each other without operat= or > assistance and expensive additional equipment which translates from one > vendor's protocol to another. A standard way of describing the multiple > streams constituting the media flows and the fundamental aspects of their > behavior, would allow telepresence systems to interwork.**** > > ** ** > > NEW: **** > > Although telepresence systems are based on open standards such as > RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of > protocols, they cannot easily interoperate with each other without operat= or > assistance and expensive additional equipment which translates from one > vendor's protocol to another. **** > > The basic features that give telepresence its distinctive characteristics > are implemented in disparate ways in different systems. Currently > Telepresence systems from diverse vendors interoperate to some extent, > but this is not supported in a standards based fashion. Interworking > requires that translation and transcoding devices be included in the > architecture. Such devices increase latency, reducing the quality of > interpersonal interaction. Use of these devices is often not automatic; > it frequently requires substantial manual configuration and a detailed > understanding of the nature of underlying audio and video streams. This > state of affairs is not acceptable for the continued growth of > telepresence - telepresence systems should have the same ease of > interoperability as do telephones. Thus, a standard way of describing the > multiple streams constituting the media flows and the fundamental aspects > of their behavior, would allow telepresence systems to interwork.**** > > ** ** > > - Section 3.4, 5th paragraph : This seems misplaced as there isn't > anywhere else in the document where we talk about protocols (this is > something which would really be more appropriately discussed in the > solution documents). I would suggest to delete this paragraph. **** > > ** ** > > Nits:**** > > -------**** > > - Section 1, 3rd paragraph, 1st sentence: "draft"->"document", > "requirements will be derived" -> "requirements are derived"**** > > - Section 1, last paragraph: Need to add two spaces after "This document > structure is as follows:" **** > > - Section 2, "users we will call participant cameras" -> "users are > referred to as participant cameras" (consistent with wording a couple > sentences down) **** > > - Section 3, first sentence. Adding spacing after the sentence. **** > > - Section 3.7, first paragraph, 1st sentence. Adding spacing after the > sentence.**** > > - Section 3.9, first paragraph, last sentence. This is awkwardly worded. > I suggest changing: "assist the process of the surgery" to simply "assist > in the surgery" or "assist in the surgical process" **** > > - Section 4. 1st para. "draft" -> "document"**** > --047d7bf0e14e463b6f04e5fb516c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thanks Roni. =A0I have reviewed the updated version and wi= ll retract my comment with regards to the H.239 reference. =A0I will submit= the PROTO write-up as soon as I have responses from all the authors with r= egards to IPR.=A0

Thanks,
Mary.


On Sat, Sep 7, 2013 at 3:10 AM, Roni E= ven <ron.even.tlv@gmail.com> wrote:

Hi,

I submitted 07 version including the comment and nits.

I have problem with removing the follow= ing text from section 3.4 so I am asking for more feedback.

=A0

=93In H.323[ITU= .H323] systems, H.239[ITU.H239] is typically used to

=A0=A0 control the video presentation str= eam.=A0 In SIP systems, similar

=A0= =A0 control mechanisms can be provided using BFCP [RFC4582] for

=A0=A0 presentation token.=A0 These mechanisms are suitable= for managing a

=A0=A0 single= presentation stream.=94

=A0

My view is that =A0using H.239 is the current =A0u= se case for presentation.

Roni

=A0

=A0<= /p>

From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ma= ry Barnes
Sent: 03 September, 2013 6:07 PM
To: CLUE
Cc: Ro= ni Even
Subject: [clue] Preparing PROTO Write-up for Use case doc= ument

=A0=

Hi all,

=A0

In the process of re-reviewing the use cases document in pr= eparation of the PROTO write-up, I came across the following nits and a cou= ple minor issues that I would like to discuss with the WG.=A0=

=A0

Thanks,

M= ary.

=A0

Minor issues:

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

=A0

- Section= 2, first two paragraphs after numbered list. =A0I struggled a little bit w= ith this text (which is more of a problem statement) in a section that'= s providing an overview of scenarios. I would suggest to move the first of = those two paragraphs into section 1 and delete that 2nd paragraph (in secti= on 2) =A0as I think what's important is the current last sentence of th= e 2nd paragraph in section 1. =A0Thus, I'm suggesting changing the 2nd = paragraph in section 1 as follows:

OLD:

Although telepresence systems are based on open standards su= ch as RTP[RFC3550], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of = protocols, they cannot easily interoperate with each other without operator= assistance and expensive additional equipment which translates from one ve= ndor's protocol to another. A standard way of describing the multiple s= treams constituting the media flows and the fundamental aspects of their be= havior, would allow telepresence systems to interwork.=

=A0

NEW:=A0

<= span>A= lthough telepresence systems are based on open standards such as RTP[RFC355= 0], SIP [RFC3261], H.264, and the H.323[ITU.H323] suite of protocols, they = cannot easily interoperate with each other without operator assistance and = expensive additional equipment which translates from one vendor's proto= col to another.=A0

The basic features that give telepresence= its distinctive characteristics a= re implemented in disparate ways in different systems. Currently Telepresence systems from diverse vendors interoperate to some extent, but this = is not supported in a standards bas= ed fashion. Interworking requires that translation and<= span style=3D"font-size:13.5pt;font-family:"Times","serif&qu= ot;"> transcoding devices be included in the architecture. Su= ch devices increase latency, reduci= ng the quality of interpersonal interaction. Use of these devices is often not automatic; it frequently requir= es substantial manual configuration= and a detailed understanding of the is not acceptable for the continued grow= th of telepresence - telepresence s= ystems should have the same ease of interoperability as= do telephones. Thus, a standard way of describing the = multiple streams constituting the media flows and the fundamental aspects o= f their behavior, would allow telepresence systems to interwork.

=A0

- Section 3.4, 5th paragraph : =A0This seems misplaced as th= ere isn't anywhere else in the document where we talk about protocols (= this is something which would really be more appropriately discussed in the= solution documents). =A0I would suggest to delete this paragraph. =A0

=A0

Nits:

---= ----

- Section 1, 3rd pa= ragraph, 1st sentence: "draft"->"document", "re= quirements will be derived" -> "requirements are derived"=

- Section 1, last paragraph: Need to add = two spaces after "This document structure is as follows:" =A0=A0<= u>

- Section 2, "users= we will call participant cameras" -> "users are referred to a= s participant cameras" =A0(consistent with wording a couple sentences = down)=A0

- Section 3, first sentence. =A0Adding sp= acing after the sentence.=A0

- Section 3.7, first paragraph, 1st sentence. =A0Adding spacing after = the sentence.

- Section 3.9, first paragraph, last sent= ence. =A0This is awkwardly worded. I suggest changing: "assist the pro= cess of the surgery" to simply "assist in the surgery" or &q= uot;assist in the surgical process"=A0

- Section 4. =A01st para. "draft&quo= t; -> "document"


--047d7bf0e14e463b6f04e5fb516c-- From Christian.Groves@nteczone.com Mon Sep 9 18:45:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ECE21F9C54 for ; Mon, 9 Sep 2013 18:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+CcWcjC-w1H for ; Mon, 9 Sep 2013 18:45:08 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id C806421F9BF3 for ; Mon, 9 Sep 2013 18:45:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBALh4LlJ20Z7A/2dsb2JhbAANToM/wm4IgT6DGQEBAQMBAQEBNRsVBgoBEAsYCRYPCQMCAQIBFTAGDQEFAgEBh3gSsBWTBY43gTQHhB0DmSSTaYFY Received: from ppp118-209-158-192.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.158.192]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Sep 2013 11:15:05 +0930 Message-ID: <522E799D.7020606@nteczone.com> Date: Tue, 10 Sep 2013 11:45:01 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jonathan Lennox References: <522DA473.7010506@nteczone.com> <98A86F5F-5DEA-4646-9DF0-C99FEA290AD2@vidyo.com> In-Reply-To: <98A86F5F-5DEA-4646-9DF0-C99FEA290AD2@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Roles - Conference System Control Role X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:45:09 -0000 Hello Jonathan, Please see my comments below. Regards, Christian On 10/09/2013 5:37 AM, Jonathan Lennox wrote: > Hi, Christian -- > > What I'm trying to understand (for all three of your proposed role attributes) is the use cases in which they'd be used. Are they intended for automatic (machine) consumption, or human? [CNG] The parameters are intended for both automatic and/or human consumption. That is the idea behind having a a defined set of enumerations/keywords and data types. It allows automatic parsing of the information because systems because different systems will use the enumeration rather than using slightly different terms to describe essentially the same "role" or piece of information. The "role information" (i.e. information associated with the three attributes) could be provided in several ways. i.e. when the conference is booked, automatic means such as an app on the participants smart phone that shares information or manually configured at the time of the meeting. The advertiser can then share this information with the consumer. The consumer could automatically parse some information based on a local policy, display information to prompt a user selection and potential use the information when it renders a capture (i.e. display text). > > As I mentioned in the face-to-face meeting, why should these be part of CLUE, as opposed to XCON or something similar as part of the meeting roster information? [CNG] It needs to be in CLUE because a consumer needs to be able to choose which captures to receive based on this information. It may wish to chose one capture over another based on this information. If this information is received after the captures are chosen it will result in a renegotiation with a possible change of media etc. which isn't desirable for the user experience. > > What should endpoints do in circumstances where the role types are entirely unlike the classic corporate-meeting model, e.g. our doctor's-surgery use case? [CNG] This depends on the attribute and the information they want to present. The vCard attribute is able to be used in any scenario. The structure of the information isn't going to change. People still have names, it allows to say Dr., etc. For the meeting roles I agree that not all the values would be used in a telemedical case. Participant, Presenter, Translator, may still be valid roles. In my draft I recognised the need to be able to have a "free text" field for user defined roles. This could be used to designate the roles outside a class corporate-meeting model, i.e. anaesthetist, surgeon, nurse etc. It isn't possible to enumerate every permutation and role but I believe that it is possible to come up with a list that will cover the majority of cases. > > Are there any existing conferencing or telepresence systems that carry this sort of information, and how is it used in the system? [CNG] There's nothing formal that I'm aware of. I see CLUE as a new protocol that enables new and enhanced functions to provide a better experience to consumers. As I mention in the draft providing information about people in a conference is part of that. Its an extension of behaviour that we do in live meetings i.e. why do we put a little sign on the table in front of the chairman? Why do people mingle before a meeting and exchange business cards? > > On Sep 9, 2013, at 6:35 AM, Christian Groves wrote: > >> Hello >> >> To follow up on my draft > > on >> roles I'm proposing some text for the framework for 3 new attributes to >> stimulate some discussion. I'll keep each of the attributes in a >> separate thread as there may be different issues for each attribute. >> >> My proposed text to add to the framework for conference system control >> role is: >> >> In 6.1.1 Media Capture Attributes: >> >> Conference System Control Role: >> >> This attribute indicates that the person depicted in the media capture >> has certain conference control responsibilities. It does not provide any >> authorisation in a conference management system for these conference >> control roles. The information is provided as a means for the consumer >> to select media captures and for display/playout purposes. >> >> The conference system control roles attribute has the following values: >> >> Presenter Indicates a person that can share content/media with >> others. May also be known as speaker. >> >> Controller Indicates the person responsible for controlling >> admission to the conference. Sets up the meeting, >> adds and shares contents, control who presents and >> talks. Also known as "host". >> >> Participant Indicates a participant in the conference who does >> not have any special control. Receives media and >> content from presenter. >> >> Unlike meeting role a person can only have one conference system >> control role at a time. However as multiple people can be captured >> in a media capture the conference system control role may have >> multiple values. >> >> Comments? >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > -- > Jonathan Lennox > jonathan@vidyo.com > > > From Christian.Groves@nteczone.com Mon Sep 9 18:53:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727E121E8108 for ; Mon, 9 Sep 2013 18:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uid7MYDlrZ3N for ; Mon, 9 Sep 2013 18:53:30 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id B27FD21E8119 for ; Mon, 9 Sep 2013 18:53:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBABJ7LlJ20Z7A/2dsb2JhbAANToM/wneBPoMZAQEBBAEBATUbGwoBDAQLEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQGICrAakwWPawcGhBcDmSSTaQ Received: from ppp118-209-158-192.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.158.192]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Sep 2013 11:23:28 +0930 Message-ID: <522E7B94.6080002@nteczone.com> Date: Tue, 10 Sep 2013 11:53:24 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <522DA46E.9050506@nteczone.com> <949EF20990823C4C85C18D59AA11AD8B09F5E3@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B09F5E3@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Roles - Meeting Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 01:53:31 -0000 Hello Keith, Is this a rhetorical question? I'd thought you'd been in enough plenary meetings to understand why :-). But seriously... I took the view that meeting roles are effectively assigned by the person who comes up with the agenda for the meeting. If they say someone is the vice-chairman, then so be it. They determine the measure of assistance. The vice-chairman may or may not do or say anything in the meeting, but it doesn't detract from the fact that an organisation or person has designated that person as the "vice-chairman". Regards, Christian On 9/09/2013 9:23 PM, DRAGE, Keith (Keith) wrote: > Do we need the role of vice chairman. > > The normal definition of vice chairman (I agree not the one given here) is one who substitutes for the chairman in their absence) which effectively means they become the chairman. > > Any of the other roles could be an assistant to the chairman, so unless we agree what the measure of that assistance is - then we have no idea what that role is. > > As stated any of these roles can be duplicated, so we could have multiple chairmen. > > Conversely (and not something I am proposing), if we are introducing the idea of a hierarchy within a role, then that could be applied to other roles as well, e.g. chief secretary, second secretary, third secretary. > > Keith > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Christian Groves >> Sent: 09 September 2013 11:35 >> To: clue@ietf.org >> Subject: [clue] Roles - Meeting Roles >> >> Hello >> >> To follow up on my draft > > >> on >> roles I'm proposing some text for the framework for 3 new attributes to >> stimulate some discussion. I'll keep each of the attributes in a >> separate thread as there may be different issues for each attribute. >> >> My proposed text to add to the framework for meeting roles is: >> >> In 6.1.1 Media Capture Attributes: >> >> Meeting Role: >> >> This attribute indicates the meeting role of the participant/s in the >> capture. The meeting role relates to the function the participant/s >> have >> with respect to running the meeting. As a media capture may capture >> more >> than one person the attribute more than one value per media capture. >> A >> person may also have more than one meeting role, i.e. a secretary and >> time keeper. Multiple people within a capture may also have the same >> role, i.e. three people in a capture may all be participants. In >> such a case a meeting role attribute would only need a single value >> "participant". >> >> The meeting role attribute has the following meeting roles: >> >> Chairman A person who convenes the meeting and presides over >> discussions. Also known as a moderator or >> rapporteur. >> >> ViceChairman A person who assist the chairman. >> >> Secretary A person who is responsible for documenting the >> meeting. Also known as a scribe, recorder or minute >> taker. >> >> Participant A person who is participating in a meeting that has >> no other role in a meeting. Also known as a member, >> participant or audience. >> >> Presenter A person who has been invited to present a message to >> the meeting. Also known as a lecturer. >> >> Translator A person who translates from one language to another >> in a meeting. >> >> Timekeeper A person who is responsible who records the time >> taken for the meeting. >> >> In addition this attribute supports a text field to allow an endpoint >> to provide a user defined meeting role. >> >> Comments? >> >> Regards, Christian >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Sep 9 19:35:47 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D9611E8130 for ; Mon, 9 Sep 2013 19:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCRKT4Y4JSn5 for ; Mon, 9 Sep 2013 19:35:43 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 984CE11E80FA for ; Mon, 9 Sep 2013 19:35:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBADWELlJ20Z7A/2dsb2JhbAANToM/wnqBPoMZAQEBAwEBAQE1GxUGChELGAkWDwkDAgECARUwEwYCAQGHeBKwHJMKj3KEHQOZJJNpgVYH Received: from ppp118-209-158-192.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.158.192]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Sep 2013 12:05:40 +0930 Message-ID: <522E8575.2050804@nteczone.com> Date: Tue, 10 Sep 2013 12:35:33 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <522DA473.7010506@nteczone.com> <522E2853.9020903@alum.mit.edu> In-Reply-To: <522E2853.9020903@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Roles - Conference System Control Role X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 02:35:47 -0000 Hello Paul, Please see my comments below. Regards, Christian On 10/09/2013 5:58 AM, Paul Kyzivat wrote: > Christian, > > Regarding Presenter and Participant, I'm confused about how you see > them being used in different types of conferences: > > - in our traditional TP conference, with several "rooms" that > operate as peers, are all of them Presenters? Speakers? Both? [CNG] In this case where there is no floor control being used then it wouldn't be necessary to send this attribute as there is no "conference control". Everyone can speak, listen etc. > > - in a conference like the above, but where we also have floor > control over a presentation capture, does the Presenter role > move around with the floor assignment? If so, who changes it? > Must the endpoint getting the floor do it? Or the focus? [CNG] Where there is floor control then that's where I see the potential use of this parameter. It effectively gives the initial state of the conference system control roles this can then be used by the consumer to choose the appropriate captures. I think that BFCP should be used to control the assignment once the initial CLUE is established to prevent the need for both BFCP and CLUE updates however this would need the captureID concept to be incorporated into BFCP. From a RFC4582 perspective "Controller" is equivalent to "floor chair", "Participant" is equivalent to "participant" and "presenter" is equivalent to a participant that has been granted the floor. > > Thanks, > Paul > > On 9/9/13 6:35 AM, Christian Groves wrote: >> Hello >> >> To follow up on my draft > > >> on >> roles I'm proposing some text for the framework for 3 new attributes to >> stimulate some discussion. I'll keep each of the attributes in a >> separate thread as there may be different issues for each attribute. >> >> My proposed text to add to the framework for conference system control >> role is: >> >> In 6.1.1 Media Capture Attributes: >> >> Conference System Control Role: >> >> This attribute indicates that the person depicted in the media capture >> has certain conference control responsibilities. It does not provide any >> authorisation in a conference management system for these conference >> control roles. The information is provided as a means for the consumer >> to select media captures and for display/playout purposes. >> >> The conference system control roles attribute has the following values: >> >> Presenter Indicates a person that can share content/media with >> others. May also be known as speaker. >> >> Controller Indicates the person responsible for controlling >> admission to the conference. Sets up the meeting, >> adds and shares contents, control who presents and >> talks. Also known as "host". >> >> Participant Indicates a participant in the conference who does >> not have any special control. Receives media and >> content from presenter. >> >> Unlike meeting role a person can only have one conference system >> control role at a time. However as multiple people can be captured >> in a media capture the conference system control role may have >> multiple values. >> >> Comments? >> >> Regards, Christian >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Sep 9 21:06:17 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E15B11E8156 for ; Mon, 9 Sep 2013 21:06:17 -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=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pPk-FidEF51v for ; Mon, 9 Sep 2013 21:06:13 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE5511E80FB for ; Mon, 9 Sep 2013 21:06:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAIyZLlJ20Z7A/2dsb2JhbAANNBcDDoMxwn2BQIMZAQEBBAEBATUbAhECBgoBDAQLDgMDAQIBCQsEBwUDBwkDAgECAQ8GHwkHAQYNAQUCAQGHbAMbM68zhRSEOg2JL4Ush0MPgSQbgQgWEAcGCweEBQOWDIMYiwiHfhJRgV8 Received: from ppp118-209-158-192.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.158.192]) by ipmail07.adl2.internode.on.net with ESMTP; 10 Sep 2013 13:36:04 +0930 Message-ID: <522E9AA4.4020306@nteczone.com> Date: Tue, 10 Sep 2013 14:05:56 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <1066539601.49380.1378217600179.JavaMail.nobody@jva2tc113.webex.com> <522DD8A0.402@alum.mit.edu> <522E4782.5010600@alum.mit.edu> In-Reply-To: <522E4782.5010600@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] REMINDER: CLUE WG Signaling Design Team, tomorrow, Tuesday 10-sep X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 04:06:17 -0000 Hello Paul, Given the time I'm not sure that I will participate, some comments to the open questions: Do we distinguish between the CLUE channel and overall CLUE behavior? Do we handle options/extensions via versioning, or separate from versioning? Do we have any examples of options to work with? [CNG] I think this depends on how we see the mechanism that will be used to update CLUE. For example: we might say that any syntax updates to core concepts (e.g. capture/scene/cse) needs a new version however new attributes could be introduced without update to the version. The support of these new attributes (or values) could be indicated via options/extensions. Do we establish once for a session? Or permit changes during a session? [CNG] To keep things easy I think that any version negotiation should only occur once in a session. It seems to me that the CLUE protocol version update would only be associated with a upgrade of the endpoint SW. It seems unnecessary to do this whilst a session is established. Do we negotiate in SIP, SDP, or in the CLUE channel? [CNG] As CLUE is effectively subordinate to a session control protocol I thought that the version and options could be negotiated via that. What naming/numbering scheme? [CNG] I would say keep it simple with a single integer. I don't see that major and minor versions are necessary. What requirements for backward compatibility? [CNG] I think that any changes need to be backwards compatible. I think that we should adopt the principles in 3.1.4/[draft-kyzivat-clue-signaling]. Having said the above I see that the actual proposal goes against many of the comments. In general I'm OK with the proposal because I think that with versioning its just a case of picking a method and running with it. I'm still not convinced by the major and minor version thing as I haven't seen successful use of this in protocols. If we go down this approach and use in protocol messages then we need to mandate that at least the version handling messages/syntax cannot change between versions. Regards, Christian On 10/09/2013 8:11 AM, Paul Kyzivat wrote: > I put the ppt I will be using tomorrow on the wiki. > You can pull it directly from: > > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/WikiStart/CLUE%20versioning.10sep13.pptx > > > Thanks, > Paul > > On 9/9/13 10:18 AM, Paul Kyzivat wrote: >> The first of the new series of design team meetings will be Tuesday Sept >> 10. >> (See below for time.) >> >> The new series is concentrating on the CLUE signaling. >> This meeting is open to all who are willing to contribute. >> Contribute means that you volunteer to provide text. >> >> We have a set of volunteers, and they are the people I expect to have >> call in: >> Simon, Roberta, Christer, Rob, Roni, and maybe Jonathan. >> (Others willing to contribute are welcome. If you'd like to join, please >> contact me so we can discuss your role.) >> >> For this first session I've promised to take the lead on the issue of: >> Approach to versioning/options/extensions. >> I won't have text in the draft for this by then, but I will have a >> specific proposal, in PPT form. >> >> Thanks, >> Paul >> >> -------- Original Message -------- >> Subject: (Forward to attendees) Meeting invitation: CLUE WG >> Signaling >> Design Team >> Resent-Date: Tue, 3 Sep 2013 10:13:33 -0400 >> Resent-From: wg-alias-bounces@tools.ietf.org >> Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu >> Date: Tue, 3 Sep 2013 14:13:20 +0000 (GMT) >> From: Clue Working Group >> Reply-To: clue-chairs@tools.ietf.org >> To: clue-chairs@tools.ietf.org >> >> >> >> >> **** You can forward this email invitation to attendees **** >> >> Hello , >> >> Clue Working Group invites you to attend this online meeting. >> >> Topic: CLUE WG Signaling Design Team >> Date: Tuesday, September 10, 2013 >> Time: 8:30 am, Central Daylight Time (Chicago, GMT-05:00) >> Meeting Number: 646 255 438 >> Meeting Password: 1234 >> >> >> ------------------------------------------------------- >> To join the online meeting (Now from mobile devices!) >> ------------------------------------------------------- >> 1. Go to >> https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&RT=MiM3 >> >> >> >> 2. If requested, enter your name and email address. >> 3. If a password is required, enter the meeting password: 1234 >> 4. Click "Join". >> >> To view in other time zones or languages, please click the link: >> https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&PW=NNDQyYmUwYTU4&ORT=MiM3 >> >> >> >> >> ------------------------------------------------------- >> To join the audio conference only >> ------------------------------------------------------- >> Call-in toll number (US/Canada): 1-650-479-3208 >> >> Access code:646 255 438 >> >> ------------------------------------------------------- >> For assistance >> ------------------------------------------------------- >> 1. Go to https://ietf.webex.com/ietf/mc >> 2. On the left navigation bar, click "Support". >> >> You can contact me at: >> clue-chairs@tools.ietf.org >> >> >> To add this meeting to your calendar program (for example Microsoft >> Outlook), click this link: >> https://ietf.webex.com/ietf/j.php?ED=234233512&UID=0&ICS=MI&LD=1&RD=2&ST=1&SHA2=AAAAAs4wxodSid4H6UBgrF-kJ6kSpPUMhaRJyeYRYM3ZPM23&RT=MiM3 >> >> >> >> >> The playback of UCF (Universal Communications Format) rich media files >> requires appropriate players. To view this type of rich media files in >> the meeting, please check whether you have the players installed on your >> computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. >> >> Sign up for a free trial of WebEx >> http://www.webex.com/go/mcemfreetrial >> >> http://www.webex.com >> >> CCP:+16504793208x646255438# >> >> IMPORTANT NOTICE: This WebEx service includes a feature that allows >> audio and any documents and other materials exchanged or viewed during >> the session to be recorded. By joining this session, you automatically >> consent to such recordings. If you do not consent to the recording, >> discuss your concerns with the meeting host prior to the start of the >> recording or do not join the session. Please note that any such >> recordings may be subject to discovery in the event of litigation. >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Tue Sep 10 04:04:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82B21E8144 for ; Tue, 10 Sep 2013 04:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inOsY-2cQw2q for ; Tue, 10 Sep 2013 04:04:32 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 6423D21E80F7 for ; Tue, 10 Sep 2013 04:04:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArYBAG/8LlJ20Z7A/2dsb2JhbAANTsd9bYJrG2I0AkwNCAEBtGOTD44vhVADrROBWA Received: from ppp118-209-158-192.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.158.192]) by ipmail06.adl2.internode.on.net with ESMTP; 10 Sep 2013 20:34:30 +0930 Message-ID: <522EFCB9.70501@nteczone.com> Date: Tue, 10 Sep 2013 21:04:25 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] CLUE Fallback X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 11:04:33 -0000 Hello I've been having some off-line discussions with Paul K regarding whether a CLUE session needs to stay active for an entire session once established (barring any failures). I mentioned a "fallback to audio scenario". E.g. a case where a user is participating through a CLUE enabled mobile or PC using video but then wants to transition back to audio mode (they don't require or have telepresence capabilities) because they want to start moving around or they don't want to be part of the video feed anymore. In this case I think there could be a need for a procedure to allow an Advertiser to close a CLUE association but keep the audio from the session active. Effectively this is opposite procedure to first establishing a "legacy" media session and then upgrading it to a full CLUE session. 3GPP has similar type of functionality CS Multimedia drop back to audio and a requirement in IMS Multimedia to drop video streams back to audio. What are people's thoughts? Regards, Christian From keith.drage@alcatel-lucent.com Tue Sep 10 04:08:44 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF59421E8140 for ; Tue, 10 Sep 2013 04:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3u7aQMBgabL for ; Tue, 10 Sep 2013 04:08:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1899021E80F7 for ; Tue, 10 Sep 2013 04:08:39 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r8AB8aCF000619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Sep 2013 06:08:37 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r8AB8WQe013287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 13:08:35 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 10 Sep 2013 13:08:34 +0200 From: "DRAGE, Keith (Keith)" To: Christian Groves Thread-Topic: [clue] Roles - Meeting Roles Thread-Index: AQHOrciIAIzDikkNHUCmduXj3D9Y5Zm+y2Xg Date: Tue, 10 Sep 2013 11:08:33 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0A135A@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <522DA46E.9050506@nteczone.com> <949EF20990823C4C85C18D59AA11AD8B09F5E3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <522E7B94.6080002@nteczone.com> In-Reply-To: <522E7B94.6080002@nteczone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "clue@ietf.org" Subject: Re: [clue] Roles - Meeting Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 11:08:45 -0000 Ah, so you mean the real definition is the one who runs the projector. No it was not a rhetorical question - vice chair is essentially a role in w= aiting, rather than a current role, and therefore I don't believe we should= assign the name to a function which is not well specified. There can be all sorts of titles applied in the organization that have zero= impact on the way the conference operates and vice chair is one of those. If we had a monarch role, would we need an heir to the throne role, and if = so why? Keith > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: 10 September 2013 02:53 > To: DRAGE, Keith (Keith) > Cc: clue@ietf.org > Subject: Re: [clue] Roles - Meeting Roles >=20 > Hello Keith, >=20 > Is this a rhetorical question? I'd thought you'd been in enough plenary > meetings to understand why :-). >=20 > But seriously... I took the view that meeting roles are effectively > assigned by the person who comes up with the agenda for the meeting. If > they say someone is the vice-chairman, then so be it. They determine the > measure of assistance. The vice-chairman may or may not do or say > anything in the meeting, but it doesn't detract from the fact that an > organisation or person has designated that person as the "vice-chairman". >=20 > Regards, Christian >=20 > On 9/09/2013 9:23 PM, DRAGE, Keith (Keith) wrote: > > Do we need the role of vice chairman. > > > > The normal definition of vice chairman (I agree not the one given here) > is one who substitutes for the chairman in their absence) which > effectively means they become the chairman. > > > > Any of the other roles could be an assistant to the chairman, so unless > we agree what the measure of that assistance is - then we have no idea > what that role is. > > > > As stated any of these roles can be duplicated, so we could have > multiple chairmen. > > > > Conversely (and not something I am proposing), if we are introducing th= e > idea of a hierarchy within a role, then that could be applied to other > roles as well, e.g. chief secretary, second secretary, third secretary. > > > > Keith > > > >> -----Original Message----- > >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf O= f > >> Christian Groves > >> Sent: 09 September 2013 11:35 > >> To: clue@ietf.org > >> Subject: [clue] Roles - Meeting Roles > >> > >> Hello > >> > >> To follow up on my draft >> clarifications/>> > >> on > >> roles I'm proposing some text for the framework for 3 new attributes t= o > >> stimulate some discussion. I'll keep each of the attributes in a > >> separate thread as there may be different issues for each attribute. > >> > >> My proposed text to add to the framework for meeting roles is: > >> > >> In 6.1.1 Media Capture Attributes: > >> > >> Meeting Role: > >> > >> This attribute indicates the meeting role of the participant/s in > the > >> capture. The meeting role relates to the function the > participant/s > >> have > >> with respect to running the meeting. As a media capture may > capture > >> more > >> than one person the attribute more than one value per media > capture. > >> A > >> person may also have more than one meeting role, i.e. a secretary > and > >> time keeper. Multiple people within a capture may also have the > same > >> role, i.e. three people in a capture may all be participants. In > >> such a case a meeting role attribute would only need a single > value > >> "participant". > >> > >> The meeting role attribute has the following meeting roles: > >> > >> Chairman A person who convenes the meeting and presides > over > >> discussions. Also known as a moderator or > >> rapporteur. > >> > >> ViceChairman A person who assist the chairman. > >> > >> Secretary A person who is responsible for documenting the > >> meeting. Also known as a scribe, recorder or > minute > >> taker. > >> > >> Participant A person who is participating in a meeting that > has > >> no other role in a meeting. Also known as a > member, > >> participant or audience. > >> > >> Presenter A person who has been invited to present a messag= e > to > >> the meeting. Also known as a lecturer. > >> > >> Translator A person who translates from one language to > another > >> in a meeting. > >> > >> Timekeeper A person who is responsible who records the time > >> taken for the meeting. > >> > >> In addition this attribute supports a text field to allow an > endpoint > >> to provide a user defined meeting role. > >> > >> Comments? > >> > >> Regards, Christian > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Tue Sep 10 06:07:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CD211E81AC for ; Tue, 10 Sep 2013 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-b-WJX7dopU for ; Tue, 10 Sep 2013 06:07:21 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A4FC711E8171 for ; Tue, 10 Sep 2013 06:07:18 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id q16so3867099ead.35 for ; Tue, 10 Sep 2013 06:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=/i5HXryJleOZF8lx+MURGz8H845ZloJyAcuujKuXzls=; b=MLqKzjJ7LBsiFyEtaBIRI9tqQ+DykwNfKFdGYqPgCWOnhjolVIWloKEH/nrmlcgo1x oHmETNtzmqq30Z3pRJBPMtspclHzo9K8o6z0Mj9XQOaR3nGRnKPDyrenDknRJ7km/A5W LO4ZjyCRvD0ECSHXx2a7ra6fpT+hBRiZVOoUoZvtecd9oMbNiqxwBEMYNFG3MAncIljL iTdk5ZQ2C+YSJSQ8rmzk00mDULa8rQQ7PpfSN/2NB48YiTJ3xy9RzqxQlmp2C6iPJGnh sW4vGQS0C08Wh6DaoiW9ENiFHVFkVtl9xH5jqzDI/PWRc4HvANtxOZSulZR220Fb+XFc BNOg== X-Received: by 10.14.214.136 with SMTP id c8mr38509647eep.6.1378818437414; Tue, 10 Sep 2013 06:07:17 -0700 (PDT) Received: from RoniE (bzq-79-181-232-77.red.bezeqint.net. [79.181.232.77]) by mx.google.com with ESMTPSA id b45sm31247929eef.4.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 10 Sep 2013 06:07:16 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , References: <522EFCB9.70501@nteczone.com> In-Reply-To: <522EFCB9.70501@nteczone.com> Date: Tue, 10 Sep 2013 16:04:31 +0300 Message-ID: <01f501ceae26$4c2d71c0$e4885540$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJeHjzKe17f5EERwB6uqD2LJ3Njl5igDwHw Content-Language: en-us Subject: Re: [clue] CLUE Fallback X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 13:07:29 -0000 Hi Christian, I think that the more general question is what happens if the CLUE channel is closed. My thinking is that if the SDP still have the media channel open then the media continues to flow. So for example in a point to point call once a steady state is achieved is there a reason to keep the CLUE channel open? In your example the closing of the CLUE channel will be followed by and RFC3264 offer that will close the video channels. Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 10 September, 2013 2:04 PM > To: clue@ietf.org > Subject: [clue] CLUE Fallback > > Hello > > I've been having some off-line discussions with Paul K regarding whether a > CLUE session needs to stay active for an entire session once established > (barring any failures). > > I mentioned a "fallback to audio scenario". E.g. a case where a user is > participating through a CLUE enabled mobile or PC using video but then > wants to transition back to audio mode (they don't require or have > telepresence capabilities) because they want to start moving around or they > don't want to be part of the video feed anymore. > > In this case I think there could be a need for a procedure to allow an > Advertiser to close a CLUE association but keep the audio from the session > active. Effectively this is opposite procedure to first establishing a "legacy" > media session and then upgrading it to a full CLUE session. > > 3GPP has similar type of functionality CS Multimedia drop back to audio and a > requirement in IMS Multimedia to drop video streams back to audio. > > What are people's thoughts? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Sep 10 06:11:56 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E6E11E81A4 for ; Tue, 10 Sep 2013 06:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.687 X-Spam-Level: X-Spam-Status: No, score=-0.687 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VX2ls-CfBmHp for ; Tue, 10 Sep 2013 06:11:51 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 629FD11E816D for ; Tue, 10 Sep 2013 06:11:38 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta09.westchester.pa.mail.comcast.net with comcast id PPU21m0040QuhwU59RBdLD; Tue, 10 Sep 2013 13:11:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id PRBd1m00F3ZTu2S3NRBd1L; Tue, 10 Sep 2013 13:11:37 +0000 Message-ID: <522F1A88.7070306@alum.mit.edu> Date: Tue, 10 Sep 2013 09:11:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <522EFCB9.70501@nteczone.com> In-Reply-To: <522EFCB9.70501@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1378818697; bh=60clfao73LrFP9lNApbndq3vxBeR378eQ5bA/K6RhiY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BGEFGWdiz8qt4QMGP5Y6F+iuqMGljqvyyN+Syzw1Kek5KvAGHDMserJIKT8r/N4XT rvYyoXZ2HPCkFBEe+PUHlBR34ugAkIsrQ1lDpcYF7c9rdImSvnyn4BBPl9C1LXPFvA BB50A7HJgquP/ubjqKufKfLKRlUp7B1hWr2sYV+Wu7gJeX6PhMEQIqN/Yo9zJ5S1/u GOcOAsiUiXrxzqLdt1vzWN7hON9i4NDhAAV0uwFKtmHnIwdrty8i1A0sWUlt1q7Eu0 lS6o39MOd3v4l4fO6+XCA2TBeBHxlWadONOnaT3OhR4Elkg2zNYs+VYSrsWtBFpHj2 VmsRnLmDV+xQQ== Subject: Re: [clue] CLUE Fallback X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 13:11:56 -0000 (as individual) I agree, now that Christian has provided a use case. I think we need a way to signal a desire to cease CLUE behavior and return to legacy mode. At that point the clue channel can be closed. Conversely, IMO, if the clue channel, or the SCTP association carrying it, is closed/dropped after clue mode has been established, then we should enter an error recovery mode where we attempt to reestablish the clue channel. And while that is going on I think media should continue to be processed according to the last successful configuration in each direction. Thanks, Paul On 9/10/13 7:04 AM, Christian Groves wrote: > Hello > > I've been having some off-line discussions with Paul K regarding whether > a CLUE session needs to stay active for an entire session once > established (barring any failures). > > I mentioned a "fallback to audio scenario". E.g. a case where a user is > participating through a CLUE enabled mobile or PC using video but then > wants to transition back to audio mode (they don't require or have > telepresence capabilities) because they want to start moving around or > they don't want to be part of the video feed anymore. > > In this case I think there could be a need for a procedure to allow an > Advertiser to close a CLUE association but keep the audio from the > session active. Effectively this is opposite procedure to first > establishing a "legacy" media session and then upgrading it to a full > CLUE session. > > 3GPP has similar type of functionality CS Multimedia drop back to audio > and a requirement in IMS Multimedia to drop video streams back to audio. > > What are people's thoughts? > > Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Tue Sep 10 19:13:51 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6821E80CD for ; Tue, 10 Sep 2013 19:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.724 X-Spam-Level: X-Spam-Status: No, score=-2.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRrYMj-uBlFJ for ; Tue, 10 Sep 2013 19:13:51 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA221F9CBF for ; Tue, 10 Sep 2013 19:13:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAITRL1J20bW2/2dsb2JhbAANToM/wy2BNYMZAQEBBAEBATUbFQYKAQwECxEEAQEBCQwKCAcJAwIBAgEVHwkIBg0BBQIBAYgKsAqSeI9bBwYEhBMDmSWTbg Received: from ppp118-209-181-182.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.181.182]) by ipmail07.adl2.internode.on.net with ESMTP; 11 Sep 2013 11:43:20 +0930 Message-ID: <522FD1BA.7010508@nteczone.com> Date: Wed, 11 Sep 2013 12:13:14 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <522DA46E.9050506@nteczone.com> <949EF20990823C4C85C18D59AA11AD8B09F5E3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <522E7B94.6080002@nteczone.com> <949EF20990823C4C85C18D59AA11AD8B0A135A@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B0A135A@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Roles - Meeting Roles X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 02:13:52 -0000 Hello Keith, You just specified the function.... the one who runs the projector :-). I agree if you only focus on performing a function at the meeting then I agree Vice-Chair is largely superflous. If you take the view that meeting role takes into account "organisation" assignments then vice-chair is relevant. E.g. I might chose captures that depict the chairman and vice-chairs because I want to see the management committee. I'm fine if we want to keep it to a functional view. I'd be interested in other's opinions. Regards, Christian On 10/09/2013 9:08 PM, DRAGE, Keith (Keith) wrote: > Ah, so you mean the real definition is the one who runs the projector. > > No it was not a rhetorical question - vice chair is essentially a role in waiting, rather than a current role, and therefore I don't believe we should assign the name to a function which is not well specified. > > There can be all sorts of titles applied in the organization that have zero impact on the way the conference operates and vice chair is one of those. > > If we had a monarch role, would we need an heir to the throne role, and if so why? > > Keith > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: 10 September 2013 02:53 >> To: DRAGE, Keith (Keith) >> Cc: clue@ietf.org >> Subject: Re: [clue] Roles - Meeting Roles >> >> Hello Keith, >> >> Is this a rhetorical question? I'd thought you'd been in enough plenary >> meetings to understand why :-). >> >> But seriously... I took the view that meeting roles are effectively >> assigned by the person who comes up with the agenda for the meeting. If >> they say someone is the vice-chairman, then so be it. They determine the >> measure of assistance. The vice-chairman may or may not do or say >> anything in the meeting, but it doesn't detract from the fact that an >> organisation or person has designated that person as the "vice-chairman". >> >> Regards, Christian >> >> On 9/09/2013 9:23 PM, DRAGE, Keith (Keith) wrote: >>> Do we need the role of vice chairman. >>> >>> The normal definition of vice chairman (I agree not the one given here) >> is one who substitutes for the chairman in their absence) which >> effectively means they become the chairman. >>> Any of the other roles could be an assistant to the chairman, so unless >> we agree what the measure of that assistance is - then we have no idea >> what that role is. >>> As stated any of these roles can be duplicated, so we could have >> multiple chairmen. >>> Conversely (and not something I am proposing), if we are introducing the >> idea of a hierarchy within a role, then that could be applied to other >> roles as well, e.g. chief secretary, second secretary, third secretary. >>> Keith >>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >>>> Christian Groves >>>> Sent: 09 September 2013 11:35 >>>> To: clue@ietf.org >>>> Subject: [clue] Roles - Meeting Roles >>>> >>>> Hello >>>> >>>> To follow up on my draft >>> > clarifications/>> >>>> on >>>> roles I'm proposing some text for the framework for 3 new attributes to >>>> stimulate some discussion. I'll keep each of the attributes in a >>>> separate thread as there may be different issues for each attribute. >>>> >>>> My proposed text to add to the framework for meeting roles is: >>>> >>>> In 6.1.1 Media Capture Attributes: >>>> >>>> Meeting Role: >>>> >>>> This attribute indicates the meeting role of the participant/s in >> the >>>> capture. The meeting role relates to the function the >> participant/s >>>> have >>>> with respect to running the meeting. As a media capture may >> capture >>>> more >>>> than one person the attribute more than one value per media >> capture. >>>> A >>>> person may also have more than one meeting role, i.e. a secretary >> and >>>> time keeper. Multiple people within a capture may also have the >> same >>>> role, i.e. three people in a capture may all be participants. In >>>> such a case a meeting role attribute would only need a single >> value >>>> "participant". >>>> >>>> The meeting role attribute has the following meeting roles: >>>> >>>> Chairman A person who convenes the meeting and presides >> over >>>> discussions. Also known as a moderator or >>>> rapporteur. >>>> >>>> ViceChairman A person who assist the chairman. >>>> >>>> Secretary A person who is responsible for documenting the >>>> meeting. Also known as a scribe, recorder or >> minute >>>> taker. >>>> >>>> Participant A person who is participating in a meeting that >> has >>>> no other role in a meeting. Also known as a >> member, >>>> participant or audience. >>>> >>>> Presenter A person who has been invited to present a message >> to >>>> the meeting. Also known as a lecturer. >>>> >>>> Translator A person who translates from one language to >> another >>>> in a meeting. >>>> >>>> Timekeeper A person who is responsible who records the time >>>> taken for the meeting. >>>> >>>> In addition this attribute supports a text field to allow an >> endpoint >>>> to provide a user defined meeting role. >>>> >>>> Comments? >>>> >>>> Regards, Christian >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue > From iesg-secretary@ietf.org Thu Sep 12 07:35:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CFE11E81A0; Thu, 12 Sep 2013 07:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2k1+rcsbJYn; Thu, 12 Sep 2013 07:35:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72EDD21F9D7A; Thu, 12 Sep 2013 07:35:09 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20130912143509.7967.88132.idtracker@ietfa.amsl.com> Date: Thu, 12 Sep 2013 07:35:09 -0700 Cc: clue@ietf.org Subject: [clue] Last Call: (Use Cases for Telepresence Multi-streams) to Informational RFC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ietf@ietf.org List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 14:35:10 -0000 The IESG has received a request from the ControLling mUltiple streams for tElepresence WG (clue) to consider the following document: - 'Use Cases for Telepresence Multi-streams' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-09-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Telepresence conferencing systems seek to create an environment that gives non co-located users or user groups a feeling of co-located presence through multimedia communication including at least audio and video signals of high fidelity. A number of techniques for handling audio and video streams are used to create this experience. When these techniques are not similar, interoperability between different systems is difficult at best, and often not possible. Conveying information about the relationships between multiple streams of media would allow senders and receivers to make choices to allow telepresence systems to interwork. This memo describes the most typical and important use cases for sending multiple streams in a telepresence conference. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-use-cases/ballot/ No IPR declarations have been submitted directly on this I-D. From pkyzivat@alum.mit.edu Sat Sep 14 18:20:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6178811E8100 for ; Sat, 14 Sep 2013 18:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.328 X-Spam-Level: X-Spam-Status: No, score=-0.328 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt4nV4AxRBgj for ; Sat, 14 Sep 2013 18:20:16 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 8497F11E80A2 for ; Sat, 14 Sep 2013 18:20:15 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id RCeG1m0021swQuc58DLFAo; Sun, 15 Sep 2013 01:20:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id RDLE1m00s3ZTu2S3bDLFzL; Sun, 15 Sep 2013 01:20:15 +0000 Message-ID: <52350B4E.2010108@alum.mit.edu> Date: Sat, 14 Sep 2013 21:20:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE References: <20130915010432.23827.47536.idtracker@ietfa.amsl.com> In-Reply-To: <20130915010432.23827.47536.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------070201000600000607000300" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379208015; bh=cc7ZkWnJCPjN3b6KE6MClZCIm9Pl5n556aSnVlq+tXY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K8+l9seWTZ8qy6zoyBOpaUstOxj3OMORlkgmFKhCJpwvameX51EsowFwXD2QFqXsB a3cOzGGL30dJHHMPcAY+R1M8zhuu4l6tcpHyg86jRIOrCRgfQMh0g7EXY3eUuRpTyI nK3xqlpxc1j92Rqmn4iTWrFLYoEVnm/IYLbjMgT9HBgonA98V1V4zwD7yN9FBVezMF WegMHn/V95VAUx6B6K6b0Ynf6X431cEH/pWRqjQUXKiW3b9JAwGZbI6shuXN1A5Fge tP97nNDnSQIez8NBBDZaKHLK5jcUudoQOm2TuS8tHrL1VfiuLmwetzOdBgyKRCyZVO hvjSc02wgSunw== Subject: [clue] New Version Notification for draft-kyzivat-clue-signaling-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 01:20:21 -0000 This is a multi-part message in MIME format. --------------070201000600000607000300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I just posted an updated version of draft-kyzivat-clue-signaling-05. The announcement is attached. My intent was to incorporate the versioning that I discussed on the team meeting last Tuesday. In doing so I tried to incorporate comments that I got at the meeting and after. As I did it, I found I couldn't avoid making other changes. In particular, the specification of message responses needed updating, and I captured some other agreements we have made along the way. And this forced me to reorganize things. The schema has been changed to incorporate the versioning messages, and changes in responses. There is still a lot wrong with this document, but I think it is better. There were remaining questions about versioning after the design team meeting. Now we have a document to refer to when making comments. So please take a look and comment further about any concerns you may have. I need scrutiny on the xml, and on the impact of backward version compatibility on xml. I hope we can talk about this at the interim this coming Tuesday, but it will depend on people getting a chance to review it before then. Thanks, Paul --------------070201000600000607000300 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: Return-Path: srs0=smny=s3=ietf.org=internet-drafts@alum.mit.edu Received: from imta02.emeryville.ca.mail.comcast.net (LHLO imta02.emeryville.ca.mail.comcast.net) (76.96.30.21) by sz0055.wc.mail.comcast.net with LMTP; Sun, 15 Sep 2013 01:04:44 +0000 (UTC) Received: from alum-mailsec-relay-10.mit.edu ([18.7.68.30]) by imta02.emeryville.ca.mail.comcast.net with comcast id RD4f1m00p0fAoYJ01D4f8L; Sun, 15 Sep 2013 01:04:41 +0000 X-CAA-SPAM: 00000 X-Authority-Analysis: v=2.1 cv=J+2TsmXS c=1 sm=1 tr=0 a=iuZv4df8I8YA4pZcw5dY6Q==:117 a=GU4rwa5YvsQnE15YQEkOQw==:17 a=C_IRinGWAAAA:8 a=lS0MHldHvS4A:10 a=uMweu7941ekA:10 a=LSVET5z0puwA:10 a=wPDyFdB5xvgA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=48vgC7mUAAAA:8 a=jGqiy6jZAAAA:8 a=974tuX9_ackA:10 a=le3PsESrbd1n3Uvmxr4A:9 a=QEXdDO2ut3YA:10 Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by alum-mailsec-relay-10.mit.edu (8.14.7/8.12.8) with ESMTP id r8F14Rvh008323 for ; Sat, 14 Sep 2013 21:04:39 -0400 X-AuditID: 1207440e-b7fe96d000003c8a-7f-523507a5408e Authentication-Results: symauth.service.identifier Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 2E.99.15498.6A705325; Sat, 14 Sep 2013 21:04:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8200F11E80A2; Sat, 14 Sep 2013 18:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43rAA+FgWXuH; Sat, 14 Sep 2013 18:04:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D8D21E8050; Sat, 14 Sep 2013 18:04:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: Christian Groves , Robert Hansen , Lennard Xiao , Paul Kyzivat , Christian Groves Subject: New Version Notification for draft-kyzivat-clue-signaling-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130915010432.23827.47536.idtracker@ietfa.amsl.com> Date: Sat, 14 Sep 2013 18:04:32 -0700 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRWlGSWpSXmKPExsXCI2Ylp7uM3TTIoH2umsWKDQdYHRg9/r7/ wBTAGMVlk5Kak1mWWqRvl8CVsWHCKeaCK5wV+w7PYGxgXMjexcjJISFgIvHl2VEWEJtRwEhi 97lXrBBxMYkL99azdTFycQgJHGGUmPd8BxOEM4lRYnrbRahuDYkZKy8wQiS2MUp0/epngXCm MUqcWvCJCaSKV0BQ4uTMJ0AJDg5mAU2J9bv0QcLMAtoSyxa+Zgax2QTkJFa/mgY2SETgHqPE rxuPwO4QFvCUeHLgGhPENhGJd1cfMkPYkhIrZrxghbhbTuLHscdgNQICAhL/Jl1ggdjrKLFw 5VWwOIuAqsSlk6vZJzCKzEJy0iyEk2YhOWkBI/MqRrnEnNJc3dzEzJzi1GTd4uTEvLzUIl1j vdzMEr3UlNJNjMDAF2J34dvB2L5e5hCjAAejEg8vw2WTICHWxLLiytxDjJIcTEqivD+ZTYOE +JLyUyozEosz4otKc1KLDzFKcDArifD+fwNUzpuSWFmVWpQPk5LmYFES51Vbou4nJJCeWJKa nZpakFoEk2XiYD/EKMPBoSTBO5MNaLJgUWp6akVaZk4JshpOEMEFsoYHaM0WkELe4oLE3OLM dIiiU4yKUuK8y0ESAiCJjNI8uAGwZHWJUVZKmJeRgYFBiAfoAqDHUeUfMQpyvGQXYuNiSs0T UJJiycvPS33FKA4MCGHeDpDJPJl5JXAbXwEdwwR0zObdRiDHlCQipKQaGDe0X5p4sauhaMa7 heJ1vLIHytxCRXMS4xVzePfnNmb2OK9L4RYRqy/4dSDx9WMhx4XT0sUKXu79vEWT6e9hvYdG EQr7unNXyUbYLBXJ387JVaxVMsHR/+tHWQeBbpstv6/OWjq3VGChgYbTYSGbx0dty40EFYzd bt8/fmXO53PWvhu/VH6br8RSnJFoqMVcVJwIALyrqVVlAwAA A new version of I-D, draft-kyzivat-clue-signaling-05.txt has been successfully submitted by Paul Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-clue-signaling Revision: 05 Title: CLUE Signaling Creation date: 2013-09-15 Group: Individual Submission Number of pages: 44 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-sig= naling-05.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signali= ng Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-05 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-kyzivat-clue-sign= aling-05 Abstract: This document specifies how signaling is conducted in the course of CLUE sessions. This includes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol that complements SIP/SDP and supports negotiation of CLUE application level data. = = Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------070201000600000607000300-- From pkyzivat@alum.mit.edu Sun Sep 15 12:32:23 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF211E8194 for ; Sun, 15 Sep 2013 12:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7s6ha4hd-fF for ; Sun, 15 Sep 2013 12:32:19 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id BC45511E8195 for ; Sun, 15 Sep 2013 12:32:17 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id RWcH1m0041ap0As5CXYHoe; Sun, 15 Sep 2013 19:32:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id RXYG1m0103ZTu2S3iXYHW8; Sun, 15 Sep 2013 19:32:17 +0000 Message-ID: <52360B40.9030702@alum.mit.edu> Date: Sun, 15 Sep 2013 15:32:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> In-Reply-To: <5224EC1A.1020603@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379273537; bh=qkd8N7mMLEnj8mn3g2eCriDFZDuDiSuoSf6foEkN6rY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oOSUHiLL355aGU2YaDEu2lwV7KLRCEgDjIQLKtjzfbwtKQLs6OqJRoUvsjWWMpKSF pUeTwcWAJSHisO+ViaKNrhKLfSDw+Vd7J2ponsjbOO4k8bfwiEb96GaDvzldcWDQfB XLU+qbMtcqmj9Nt9I0sm86DP6HIq/DJfhKPLVVO9p5H92gnnh1mAQRjwjWd4qJEkve SQNfqSGYmqt94eW8GXkbqK/4LyG5mXZahQnzpo3lH3B+iwmJOvq37ucYw3voKRWQFF +zp3UxrNL4Z0FSNJ+k2BVHUrQ42MMLUm3W5tubPJYPNPOVhlWJpLXqPY9UNrKT4+N/ W0mdqrwCdTVyw== Subject: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Sep 2013 19:32:23 -0000 We started WGLC on the requirements two weeks ago. It has run for two weeks, and there have been *NO* comments!!! :-( I can't advance this document without better indication of support from the WG. So I'm extending this WGLC. I'll be away next weekend, so I will let this extension run another two weeks, ending Sunday Sept 29. We NEED NEED NEED your comments on this. Please review it again, and respond either positively or negatively, whether you think it is ready to progress. Thanks, Paul On 9/2/13 3:50 PM, Paul Kyzivat wrote: > With this message I'm announcing the start of WGLC for > draft-ietf-clue-telepresence-requirements-05 > > This WGLC will last for roughly two weeks, ending at midnight GMT on > Sunday September 15. > > It is important to have decisive results from a WGLC. > (Silence doesn't do it.) > So please, take a last careful look at these requirements and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) > > On 8/30/13 6:39 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple streams for >> tElepresence Working Group of the IETF. >> >> Title : Requirements for Telepresence Multi-Streams >> Author(s) : Allyn Romanow >> Stephen Botzko >> Mary Barnes >> Filename : draft-ietf-clue-telepresence-requirements-05.txt >> Pages : 13 >> Date : 2013-08-30 >> >> Abstract: >> This memo discusses the requirements for a specification that enables >> telepresence interoperability, by describing the relationship between >> multiple RTP streams. In addition, the problem statement and >> definitions are also covered herein. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05 >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Sun Sep 15 17:32:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3F511E8174 for ; Sun, 15 Sep 2013 17:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAvwR1PKf2FZ for ; Sun, 15 Sep 2013 17:32:10 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 0891211E8170 for ; Sun, 15 Sep 2013 17:32:09 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id RZok1m0030EZKEL51cY9jC; Mon, 16 Sep 2013 00:32:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id RcY71m00b3ZTu2S3McY7VQ; Mon, 16 Sep 2013 00:32:09 +0000 Message-ID: <52365186.3010700@alum.mit.edu> Date: Sun, 15 Sep 2013 20:32:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379291529; bh=xS8LSVSCefWD+Ov8E0laPWgZ7+sO0cnuPij2nb+LTHQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EWQ7k4nnqPtyx2tOaKoqSeIi4XKdTS8VRiWHIZYimBe+niYw2b626TC8MlHfEHKxn R7LU55HPbQ8tGi6+ukhnrt/2mPmQWKasZIuVd/BBMvGufEc34iVvVY3z810KQBCQ7x W2TdlyzrBrnNXWhdg0Kav/5HYPIuOwvDmMWB4GHItXCnMw5jHnQMmhAL/rZRFj/NJ4 uxRICYicNsvqFa85Ixmtg8t9eQnoAWTJ3dwuYTneViOfbGMt4v1hys4jmQUZIyBdu3 pJBIDL/dz4uzAqO2+ovb2qM9SGFlKxYvB9q3Y1NZ8piqgjwqMXpkfgirE9I12C4MDB u1vFSjGurR2IA== Subject: [clue] REMINDER: CLUE WG Virtual Interim Meeting, September 17, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 00:32:19 -0000 The CLUE WG will hold an Interim meeting on: Sept. 17, 2013 13.30-15.30 UTC (starting at 6.30 Pacific, 8.30 Central, 9.30 Eastern) Webex details, Agenda, and presentations are available on the CLUE WG wiki: http://trac.tools.ietf.org/wg/clue/trac/wiki See you then, Paul From Mark.Duckworth@polycom.com Mon Sep 16 08:28:30 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F050311E829C for ; Mon, 16 Sep 2013 08:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IA9WarBN0sbs for ; Mon, 16 Sep 2013 08:28:25 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id DA87411E828C for ; Mon, 16 Sep 2013 08:28:24 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 16 Sep 2013 08:28:07 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Mon, 16 Sep 2013 08:28:05 -0700 Thread-Topic: [clue] REMINDER: CLUE WG Virtual Interim Meeting, September 17, 2013 Thread-Index: Ac6ydDbuJCM7JhSpRra30VJC8r6MngAfIzxA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D602EF5FD7@CRPMBOXPRD07.polycom.com> References: <52365186.3010700@alum.mit.edu> In-Reply-To: <52365186.3010700@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] REMINDER: CLUE WG Virtual Interim Meeting, September 17, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:28:30 -0000 Hi Paul, On the "proceedings" page I see a presentation from Christian regarding dra= ft-groves-clue-multi-content, but I don't see it on the agenda. If we have= time, it would be good to put it on the agenda. I plan to have just a sho= rt presentation about status of framework issues, which we should be able t= o get through in 10 minutes I think. The agenda has 20 minutes allocated f= or that. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Sunday, September 15, 2013 8:32 PM > To: clue@ietf.org > Subject: [clue] REMINDER: CLUE WG Virtual Interim Meeting, September 17, > 2013 >=20 > The CLUE WG will hold an Interim meeting on: > Sept. 17, 2013 13.30-15.30 UTC (starting at 6.30 Pacific, 8.30 Central, > 9.30 Eastern) >=20 > Webex details, Agenda, and presentations are available on the CLUE WG > wiki: > http://trac.tools.ietf.org/wg/clue/trac/wiki >=20 > See you then, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Mon Sep 16 08:41:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA3111E82A9 for ; Mon, 16 Sep 2013 08:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkKl3Xh5Tbhp for ; Mon, 16 Sep 2013 08:41:12 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7D05111E82A8 for ; Mon, 16 Sep 2013 08:41:12 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so1177256qaq.2 for ; Mon, 16 Sep 2013 08:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Syc9Ty6Qbh4FydHTYTe5vNOCLg+GwI42Hyc35trRCTw=; b=h1SUPiHf97hOrZnt53da0gdzlYDGVZn/xrIBdhTj3uHCFtW/V57l/XvIcWwqZNONI0 kdRRX5HrG4KuYHSnp4YhLq26gL06U2bh6VTZrrdzPtJrfQO2V3+s1ikcEQ/6cuWQd0TE SDRSL8hzhwDttU+DgCafYl0ToLOy4tlwLlCyfOI7vXo9avMyeEKzXNOpOCeLpV8UldOT hT4lVKcJhqK7c1VoD/uHWMxzpakqoDYu28KpLgJH3I/7SYC05PULbCxQRrjyQKTd3hJL MxYQ3LFWLhqR+DdqEZH9aKNfyqMH6JutN04Ygq2nn3mCldEqC9VfOiaMkjCvyuqHU+Zr Hrcw== MIME-Version: 1.0 X-Received: by 10.49.35.106 with SMTP id g10mr47793938qej.35.1379346054873; Mon, 16 Sep 2013 08:40:54 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Mon, 16 Sep 2013 08:40:54 -0700 (PDT) In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D602EF5FD7@CRPMBOXPRD07.polycom.com> References: <52365186.3010700@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D602EF5FD7@CRPMBOXPRD07.polycom.com> Date: Mon, 16 Sep 2013 10:40:54 -0500 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=047d7b6766f89f8bf704e6820724 Cc: "clue@ietf.org" Subject: Re: [clue] REMINDER: CLUE WG Virtual Interim Meeting, September 17, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 15:41:15 -0000 --047d7b6766f89f8bf704e6820724 Content-Type: text/plain; charset=ISO-8859-1 Yes, we are updating the agenda. The primary concern with spending too much time on Christian's draft is I'm not sure anyone has read it yet as there's been ZERO discussion on that document since it was posted. It's really not effective to have a presentation on a document that no one has read nor thought about prior to the meeting. We may have to defer that one to one of the design team meetings and allow folks to review and comment on so that a meeting can focus on the key concerns. It would also be good if you can get some threads started per some of the action items from the Berlin meeting: http://www.ietf.org/proceedings/87/minutes/minutes-87-clue There were a couple that required text. If we can get that on the list and get folks to consider we can quickly visit those during the meeting and get them closed by tomorrow. Mary. On Mon, Sep 16, 2013 at 10:28 AM, Duckworth, Mark < Mark.Duckworth@polycom.com> wrote: > Hi Paul, > > On the "proceedings" page I see a presentation from Christian regarding > draft-groves-clue-multi-content, but I don't see it on the agenda. If we > have time, it would be good to put it on the agenda. I plan to have just a > short presentation about status of framework issues, which we should be > able to get through in 10 minutes I think. The agenda has 20 minutes > allocated for that. > > Mark > > > -----Original Message----- > > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > > Paul Kyzivat > > Sent: Sunday, September 15, 2013 8:32 PM > > To: clue@ietf.org > > Subject: [clue] REMINDER: CLUE WG Virtual Interim Meeting, September 17, > > 2013 > > > > The CLUE WG will hold an Interim meeting on: > > Sept. 17, 2013 13.30-15.30 UTC (starting at 6.30 Pacific, 8.30 Central, > > 9.30 Eastern) > > > > Webex details, Agenda, and presentations are available on the CLUE WG > > wiki: > > http://trac.tools.ietf.org/wg/clue/trac/wiki > > > > See you then, > > Paul > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b6766f89f8bf704e6820724 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, we are updating the agenda. =A0The primary concern wi= th spending too much time on Christian's draft is I'm not sure anyo= ne has read it yet as there's been ZERO discussion on that document sin= ce it was posted. =A0 It's really not effective to have a presentation = on a document that no one has read nor thought about prior to the meeting. = =A0We may have to defer that one to one of the design team meetings and all= ow folks to review and comment on so that a meeting can focus on the key co= ncerns.=A0

It would also be good if you can get some threads started pe= r some of the action items from the Berlin meeting:

There were a couple that required text. =A0If we = can get that on the list and get folks to consider we can quickly visit tho= se during the meeting and get them closed by tomorrow.

Mary.=A0


On Mon, Sep 16, 2013 at 10:28 AM, Duckworth, Mark <Ma= rk.Duckworth@polycom.com> wrote:
Hi Paul,

On the "proceedings" page I see a presentation from Christian reg= arding draft-groves-clue-multi-content, but I don't see it on the agend= a. =A0If we have time, it would be good to put it on the agenda. =A0I plan = to have just a short presentation about status of framework issues, which w= e should be able to get through in 10 minutes I think. =A0The agenda has 20= minutes allocated for that.

Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of
> Paul Kyzivat
> Sent: Sunday, September 15, 2013 8:32 PM
> To: clue@ietf.org
> Subject: [clue] REMINDER: CLUE WG Virtual Interim Meeting, September 1= 7,
> 2013
>
> The CLUE WG will hold an Interim meeting on:
> Sept. 17, 2013 13.30-15.30 UTC (starting at 6.30 Pacific, 8.30 Central= ,
> 9.30 Eastern)
>
> Webex details, Agenda, and presentations are available on the CLUE WG<= br> > wiki:
> http://trac.tools.ietf.org/wg/clue/trac/wiki
>
> =A0 =A0 =A0 See you then,
> =A0 =A0 =A0 Paul
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--047d7b6766f89f8bf704e6820724-- From Christian.Groves@nteczone.com Mon Sep 16 21:11:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4BF11E81A3 for ; Mon, 16 Sep 2013 21:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohJKzeP4dJi2 for ; Mon, 16 Sep 2013 21:11:38 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id F240711E8338 for ; Mon, 16 Sep 2013 21:11:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsBAG3VN1J20bBp/2dsb2JhbAANQgqDP0zBD4E3gxkBAQEEAQEBNRsbBBcLGAklDwIWMBMGAgEBBRKHbwWncpMLjiSBSoQeA5NehUyTew Received: from ppp118-209-176-105.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.176.105]) by ipmail07.adl2.internode.on.net with ESMTP; 17 Sep 2013 13:41:04 +0930 Message-ID: <5237D653.901@nteczone.com> Date: Tue, 17 Sep 2013 14:10:59 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> In-Reply-To: <52360B40.9030702@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 04:11:39 -0000 Hello, Here are my comments to the WGLC: 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a means to identify the extent of individual video captures in three dimensions. Did we decide whether this was with respect to a "plane of interest" in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect) in 3 dimensions? It probably would be good to clarify this in the requirements. 2) General: At different places there are references to particular use cases. However this doesn't appear to used consistently. e.g. Regmt-9 regarding interoperability between endpoints using different numbers of streams makes references to the heterogeneous use case. The heterogeneous use cases mentions different bit rates etc, however Reqmts-8, 7 etc don't mention the use case? It seems to me that if we include references to use cases that we should be consistent. 3) REQMT-12: Rather than say "..more than two " should we use "..more than two endpoints". We don't have a definition for "site". 4) General: Do we need to have some text in the document that indicates that there may be other unspecified requirements that may be implemented? The framework has a number of attributes that aren't mentioned as part of the requirements e.g. scene description. Or alternatively do we capture this by adding a generic requirement regarding description of the content of captures/scenes? The requirements are very focussed on spatial/render aspects rather than information pertaining to the selection of captures. 5) General: There seems to be a requirement in CLUE of the ability to indicate how captures are related to resources. e.g. the STS mechanism indicates which captures may be used together (which indicates which ones can't be used together) and the CSE that groups capture resources. This seems to be an important aspect of CLUE but there doesn't appear to be a requirement driving it. Regards, Christian On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* comments!!! :-( > > I can't advance this document without better indication of support > from the WG. So I'm extending this WGLC. I'll be away next weekend, so > I will let this extension run another two weeks, ending Sunday Sept 29. > > We NEED NEED NEED your comments on this. Please review it again, and > respond either positively or negatively, whether you think it is ready > to progress. > > Thanks, > Paul > > On 9/2/13 3:50 PM, Paul Kyzivat wrote: >> With this message I'm announcing the start of WGLC for >> draft-ietf-clue-telepresence-requirements-05 >> >> This WGLC will last for roughly two weeks, ending at midnight GMT on >> Sunday September 15. >> >> It is important to have decisive results from a WGLC. >> (Silence doesn't do it.) >> So please, take a last careful look at these requirements and comment. >> If you like these as they are, please say so. >> >> Thanks, >> Paul (as co-chair) >> >> On 8/30/13 6:39 PM, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the ControLling mUltiple streams for >>> tElepresence Working Group of the IETF. >>> >>> Title : Requirements for Telepresence Multi-Streams >>> Author(s) : Allyn Romanow >>> Stephen Botzko >>> Mary Barnes >>> Filename : draft-ietf-clue-telepresence-requirements-05.txt >>> Pages : 13 >>> Date : 2013-08-30 >>> >>> Abstract: >>> This memo discusses the requirements for a specification that >>> enables >>> telepresence interoperability, by describing the relationship >>> between >>> multiple RTP streams. In addition, the problem statement and >>> definitions are also covered herein. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements >>> >>> >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05 >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Sep 16 22:20:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE4311E8357 for ; Mon, 16 Sep 2013 22:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z98-0c60e+jP for ; Mon, 16 Sep 2013 22:20:05 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 8688C11E8352 for ; Mon, 16 Sep 2013 22:20:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAB/mN1J20bBp/2dsb2JhbAANTYM/g3y9YYE3gxkBAQEEAQEBIBUbGQIIARILGAICBSECAg8CFjATBgIBAYgLp3V0khMEgSmOOQyCaYE1A60l Received: from ppp118-209-176-105.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.176.105]) by ipmail07.adl2.internode.on.net with ESMTP; 17 Sep 2013 14:49:45 +0930 Message-ID: <5237E66A.80407@nteczone.com> Date: Tue, 17 Sep 2013 15:19:38 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130915010432.23827.47536.idtracker@ietfa.amsl.com> <52350B4E.2010108@alum.mit.edu> In-Reply-To: <52350B4E.2010108@alum.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-signaling-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 05:20:05 -0000 Hello Paul, Some comments: 3.3.1 bullet 1: "Co-ordinated use of SIP and SDP" - How is this relevant to CLUE version negotiation? The negotiation is internal to the CLUE protocol. 3.3.1 bullet 1: Duplicate "CLUE message exchange" 3.3.1 bullet 1: How does a CLUE version dictate media behaviour? 3.3.2 bullet 6: I think it would be good if their was a definition of "backwards" compatible. To me ignoring something isn't backwards compatible. For something is backwards compatible when it follow these rules: 1) Existing protocol elements, i.e., procedures, attributes values, should not be changed unless a protocol error needs to be corrected or it becomes necessary to change the operation of the service that is being supported by the protocol. 2) The semantics of a message, attribute,or a value should not be changed. 3) Established rules for formatting and encoding messages and parameters should not be modified. 4) When information elements are found to be obsolete they can be marked as not used. However, the identifier for that information element will be marked as reserved. In that way it cannot be used in future versions. Figure 1: Why are two sets of messages needed? i.e. two Supported. Isn't it sufficient for the CLUE channel initiator to send what it supported and then the required indicates which of those is being used? 3.2.3 3rd Para: I haven't understood what we gain by having two sets of "supported" messages. The version proposal appears to negotiate multiple versions in the same CLUE channel, direction dependent. It seems strange for an endpoint to say "I can send v1.2, but can only receive v1.1". Why wouldn't it be sufficient just to agree on a single version for both ends of the CLUE channel? 3.2.3 Last bullet: Is the note consistent with the last bullet and the general procedure? If the CLUE channel is re-established and maintains state then there doesn't need to be another version negotiation. 3.3.5 This section only talks about "options" which I take it is there to indicate whether optional parts of the CLUE specification are implemented? How does this relate to any future extension? e.g. if an additional capture attribute is defined. Do we see that as an extension or should this be part of CLUE version update? 3.3.5.1 : I support options but I can't see the point of mediaProvider. The very fact that CLUE has been negotiated should mean that the endpoints should be able to send and receive Advertisements and Configure messages. 3.3.7 Backwards compatibility: I take it Vx is a higher version than Vy? Maybe this should be explicit. Also given that major versions are not backwards compatible perhaps we need to say Vx.y, Vx.z? 3.3.7 bullets 6,7,8: I think text such as my comment to 3.3.2 would be sufficient. 3.3.7 bullet 9: I think the current formulation is confusing. Perhaps it would be more understandable to say "If the revision does not introduce any changes to: existing protocol elements and procedures, the semantics of messages or protocol elements, established rules for formatting and encoding (other than to fix errors) then the CLUE version may remain unchanged." 3.3.8 Examples: See my above comment on the need for two supported and required messages. Regards, Christian On 15/09/2013 11:20 AM, Paul Kyzivat wrote: > I just posted an updated version of draft-kyzivat-clue-signaling-05. > The announcement is attached. > > My intent was to incorporate the versioning that I discussed on the > team meeting last Tuesday. In doing so I tried to incorporate comments > that I got at the meeting and after. > > As I did it, I found I couldn't avoid making other changes. > In particular, the specification of message responses needed updating, > and I captured some other agreements we have made along the way. > And this forced me to reorganize things. > > The schema has been changed to incorporate the versioning messages, > and changes in responses. > > There is still a lot wrong with this document, but I think it is better. > > There were remaining questions about versioning after the design team > meeting. Now we have a document to refer to when making comments. So > please take a look and comment further about any concerns you may have. > > I need scrutiny on the xml, and on the impact of backward version > compatibility on xml. > > I hope we can talk about this at the interim this coming Tuesday, but > it will depend on people getting a chance to review it before then. > > Thanks, > Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From roberta.presta@unina.it Tue Sep 17 03:01:03 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9252911E83CF for ; Tue, 17 Sep 2013 03:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EacT9LuUmmDW for ; Tue, 17 Sep 2013 03:00:54 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id BD09C11E80F3 for ; Tue, 17 Sep 2013 03:00:53 -0700 (PDT) Received: from [127.0.0.1] ([100.71.16.115]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r8HA0nd5007993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Sep 2013 12:00:51 +0200 Message-ID: <52382850.2020709@unina.it> Date: Tue, 17 Sep 2013 12:00:48 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" References: <20130917095554.3962.44448.idtracker@ietfa.amsl.com> In-Reply-To: <20130917095554.3962.44448.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130917095554.3962.44448.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070704060609090904020306" X-Antivirus: avast! (VPS 130916-1, 16/09/2013), Outbound message X-Antivirus-Status: Clean Subject: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 10:01:03 -0000 This is a multi-part message in MIME format. --------------070704060609090904020306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, we have added in this new version some considerations about protocol versioning and extension introduced in the last team call. Cheers, Roberta -------- Messaggio originale -------- Oggetto: New Version Notification for draft-presta-clue-protocol-01.txt Data: Tue, 17 Sep 2013 02:55:54 -0700 Mittente: internet-drafts@ietf.org A: Roberta Presta , Simon Pietro Romano , Simon Romano A new version of I-D, draft-presta-clue-protocol-01.txt has been successfully submitted by Roberta Presta and posted to the IETF repository. Filename: draft-presta-clue-protocol Revision: 01 Title: CLUE protocol Creation date: 2013-09-17 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-01.txt Status: http://datatracker.ietf.org/doc/draft-presta-clue-protocol Htmlized: http://tools.ietf.org/html/draft-presta-clue-protocol-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-01 Abstract: ToDo. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------070704060609090904020306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi all,

we have added in this new version some considerations about protocol versioning and extension introduced in the last team call.
Cheers,

Roberta


-------- Messaggio originale --------
Oggetto: New Version Notification for draft-presta-clue-protocol-01.txt
Data: Tue, 17 Sep 2013 02:55:54 -0700
Mittente: internet-drafts@ietf.org
A: Roberta Presta <roberta.presta@unina.it>, Simon Pietro Romano <spromano@unina.it>, Simon Romano <spromano@unina.it> 


A new version of I-D, draft-presta-clue-protocol-01.txt
has been successfully submitted by Roberta Presta and posted to the
IETF repository.

Filename:	 draft-presta-clue-protocol
Revision:	 01
Title:		 CLUE protocol
Creation date:	 2013-09-17
Group:		 Individual Submission
Number of pages: 17
URL:             http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-01.txt
Status:          http://datatracker.ietf.org/doc/draft-presta-clue-protocol
Htmlized:        http://tools.ietf.org/html/draft-presta-clue-protocol-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-01

Abstract:
   ToDo.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------070704060609090904020306-- From mary.ietf.barnes@gmail.com Tue Sep 17 05:53:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6C11E8417 for ; Tue, 17 Sep 2013 05:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTd0JQHoHeeE for ; Tue, 17 Sep 2013 05:53:00 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id CB9FC11E824C for ; Tue, 17 Sep 2013 05:52:56 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id k4so1890220qaq.6 for ; Tue, 17 Sep 2013 05:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=SsxixvhCKxvkwe4Cs6QdPo50dQlMpnVMWYgrbw0zwFw=; b=qWCNFBus2z6vuDelQXrWaJmm4LR8fhqN5NwGkqG1N7DB5TlEhUrAzsNGEBvzM+ilTE jCuuwvO0oE+N4PyXeC1MLmW1Vudam9WbGXpSFjVwnQZYQZXEive7QCeMEXkPa4VO4lS0 cBueIOFrBupDUMSLoTEQZTzasty7ilQSXcb7YvdEkQwH5com5Re0zis8yxRBT8uPIKUU sckYoCPvkW/gSlzfomKUNK5YvOHWIEgXb7vRwP/cRcsS9wzxCsR6+uOiy/60DkxPLxwz Xu6y3/qQ88tRePI+iLXiLs4JNULeeDuEQrpZEJ11sDZdWbKtxsXZc2Ay4f+HnIe8P4dd E0EQ== MIME-Version: 1.0 X-Received: by 10.224.73.137 with SMTP id q9mr2676971qaj.96.1379422376228; Tue, 17 Sep 2013 05:52:56 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 17 Sep 2013 05:52:56 -0700 (PDT) Date: Tue, 17 Sep 2013 07:52:56 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c3bed4bafab304e693cc46 Subject: [clue] CLUE Interim (Sept. 17 2013): Detailed Agenda X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 12:53:04 -0000 --001a11c3bed4bafab304e693cc46 Content-Type: text/plain; charset=ISO-8859-1 Note, there is an html detailed agenda (with links to documents) now available in the proceedings: http://www.ietf.org/proceedings/interim/2013/09/17/clue/agenda/agenda-interim-2013-clue-3 Regards, Mary. --001a11c3bed4bafab304e693cc46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Note, there is an html detailed agenda (with links to docu= ments) now available in the proceedings:


Regards,
Mary.
--001a11c3bed4bafab304e693cc46-- From pkyzivat@alum.mit.edu Tue Sep 17 09:26:31 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AD811E8523 for ; Tue, 17 Sep 2013 09:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5IU1eknpLqY for ; Tue, 17 Sep 2013 09:26:23 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3E911E84C2 for ; Tue, 17 Sep 2013 09:26:11 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta07.westchester.pa.mail.comcast.net with comcast id SBMF1m00427AodY57GSAeZ; Tue, 17 Sep 2013 16:26:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id SGSA1m0043ZTu2S3fGSAjR; Tue, 17 Sep 2013 16:26:10 +0000 Message-ID: <523882A1.7070904@alum.mit.edu> Date: Tue, 17 Sep 2013 12:26:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130917095554.3962.44448.idtracker@ietfa.amsl.com> <52382850.2020709@unina.it> In-Reply-To: <52382850.2020709@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379435170; bh=le8CnNOjr5FDTJkS+dE1M6kOjoc3qF2bccZhgYEIgsY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=odCLklE7+hm4eMEPScv8cBCr32z/8BCBWHNK8ogCzrGpM/N2aiEXrhddS1j7FA1qN OcU+xhhNayZuxoVX471K2lzVim01Z5IciFPv0xhbRRNeTDM8GKX/Zvh8pKv5yTvzCZ 7R26Y6zSy+FeBnBYCCTYdzt/wTTFdJFWzsv61ep7QBtzLezsdi3kuVNRGayysnswis WWstewlJlSPfcxZ/6cj/r+fZu+prVFDNu+Kd7SY+eUJJIFMi6RyvXuqM4a8vFFIBTY 8gJ0PeVoHYwZ62h50DfwqfdrYaxTHmn150n028fx/W7m6ABhCCxnRj1ZJN3c1cxvP/ lSiG1NFOLncfA== Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 16:26:31 -0000 Hi Roberta, Thank you for continuing this work. I need to consider this revision further regarding the state machine changes. I'll comment later on those if need be. For the moment I just want to ask some questions about the extensibility and versioning. You say: Obviously, client and server can not communicate if they do not share exactly the same XML schema. Such schema will be the one included in the to-be-written RFC, and associated with the CLUE URN "urn:ietf:params:xml:ns:clue-message". and then, When new protocol-specific information are needed somewhere in the protocol messages, they can be added in place of the elements and elements envisioned by the protocol schema. The policy currently defined in the protocol schema for handling and elements is: elementFormDefault="qualified" attributeFormDefault="unqualified" In that case, the new information must be qualified by namespaces other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN) and "urn:ietf:params:xml:ns:clue-info" (the data model URN). Elements or attributes from unknown namespaces MUST be ignored. (And similar logic for data model extensions and addition of new messages.) This implies that every extension defines another schema. Couldn't that get unpleasant? My quick reading of XMPP leads me to believe that it allows backward compatible revisions to its schema. (But I don't fully understand the implications of what it does.) Another thing - it is certainly everyone's hope that we get everything right enough the first time that we don't ever require a change that is not backward compatible. But that doesn't mean we will be successful at that. What would you suggest be done if an incompatible change is required? Would you just have this detected via a change to the namespace URN? While I see that could work, with multiple schemas, not all of which are used in every message, that could mean that an unsupported schema would not be detected until the clue session is well underway. That seems undesirable - that we would like to detect incompatibility as early as possible. Also, what about aspects of the protocol other than XML? (For instance, suppose some future extension is dependent on future extensions to SDP.) Do you think there should be some *other* version/extension mechanism for that? Thanks, Paul On 9/17/13 6:00 AM, Roberta Presta wrote: > > > Hi all, > > we have added in this new version some considerations about protocol > versioning and extension introduced in the last team call. > Cheers, > > Roberta From mary.ietf.barnes@gmail.com Tue Sep 17 10:09:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65B411E84A6 for ; Tue, 17 Sep 2013 10:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNI545FXfavQ for ; Tue, 17 Sep 2013 10:08:59 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6F25111E830A for ; Tue, 17 Sep 2013 10:08:59 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id l4so3742064qcv.24 for ; Tue, 17 Sep 2013 10:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=pI6FPTLItE7joce77xU+7MjOCFn+Ljj/9Ry2SnfwC/A=; b=RfweXmV9ILFsznN0Bepv8rGMwjt/1TYWj2t4hC7HLp7/bKnX2IIgO5kegimxwd5G5j n/6dioB07r4qE1SJ1YQHfK903r8I8JtrEmdl7HpC6GuXEdBlp9SnMBGhmFIlGcTgojCo 5n90YFdQALRFZ8yypsBOaPytBP1aPgYZ2ivBj5881nQnv8T+JX2PCpXxx1mRaeovc1ys jxTunwdtVIdxddfyq+fPl2ZOCUirVVDCCe3tZbWApJFlw3t2/pbGfb02OZL8X0bfCAv5 L2Fsyd+B581xU6bav3MKle94KmSXHlSsgYCx+l3JWK2If3EafWEoYN8sAeLK3e+QZ5DM Wp7A== MIME-Version: 1.0 X-Received: by 10.224.34.74 with SMTP id k10mr8420324qad.63.1379437737793; Tue, 17 Sep 2013 10:08:57 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 17 Sep 2013 10:08:57 -0700 (PDT) Date: Tue, 17 Sep 2013 12:08:57 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c2cd7859dcb304e69760cf Subject: [clue] Proposal for dividing and restructuring Signaling work. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 17:09:00 -0000 --001a11c2cd7859dcb304e69760cf Content-Type: text/plain; charset=ISO-8859-1 HI all, The diagram I presented is included in the proceedings in the chair charts (slide 7): Agenda & Status (Chairs) The motivation for this suggestion is that we already have another individual doc that is describing details of the CLUE protocol. I believe that keeping all the details of that in a separate document will make the work more manageable. Otherwise, I fear we will have one of those 200 page monster documents, which is difficult to share amongst multiple authors and a nightmare to progress. Even with this split, my guess is that both these documents would be anywhere from 75-100 pages when completed once we get all the details in, including error handling, IANA registrations, security, etc. So, here is my suggestion for the Abstract/Intro and ToC for the signaling document: OLD Abstract: This document specifies how signaling is conducted in the course of CLUE sessions. This includes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol that complements SIP/SDP and supports negotiation of CLUE application level data. NEW Abstract: This document specifies the signaling model for CLUE sessions. It describes the orchestration of SIP/SDP O/A with the CLUE protocol to support the CLUE use cases. This document identifies the SDP and RTP building blocks required to establish a CLUE session. New ToC: 1. Introduction 2. Terminology 3. Overview This document describes the orchestration of the SIP SDP O/A signaling with the CLUE protocol [reference]. The details of the SDP and RTP building blocks are also identified, with relevant references to the documents that are required for the overall CLUE solution. The document provides details on the mapping that is required between constructs in the CLUE Data model [ref] and SDP. This document also discusses how CLUE would operate in an environment where one or more of the participants does not support CLUE. A few examples are provided. A separate document provides additional detailed call flows of the realization of the CLUE use cases based upon the protocol details defined in this document. --- A nice diagram would also help. [In my opinion, this is a better place to introduce all the CLUE solution work, which I previously suggested should be in the Framework.] 4. CLUE use of SDP O/A 4.1. Establishing the CLUE channel 4.2. Representing CLUE Encodings in SDP 4.3. Representing CLUE Encoding Groups in SDP 4.4. Signaling CLUE control of "m" lines 4.5. Ensuring interoperability with non-CLUE devices 5. Interaction of CLUE and SDP negotiations 5.1 Independence of SDP and CLUE negotiation 5.2. Recommendations for operating with non-atomic operations 5.3. Constraints on sending media 6. Example: A call between two CLUE-capable endpoints 7. Example: A call between a CLUE and non-CLUE-capable endpoint 38 8. CLUE requirements on SDP O/A 9. SIP Signaling 10. Interoperation with non-CLUE aware SIP Devices [I'd rather ditch the term "legacy"] 11. CLUE over RTCWEB ....remainder is the same.... Here's the suggestion for the Abstract/Intro and ToC for the CLUE protocol document: This document provides the details for the CLUE protocol based upon the constructs defined in the CLUE framework. The CLUE protocol is used in conjunction with SIP/SDP to establish CLUE sessions to support the CLUE use cases. The CLUE protocol is based on an XML schema that provides versioning and extensibility. The CLUE protocol carries CLUE information, as identified in the framework, in the form of XML documents and fragments conforming to the CLUE data model schema. Toc: 1. Introduction 2. Terminology 3. Overview of the CLUE protocol messages 3.1. ADVERTISEMENT 3.2. CONFIGURE 3.3. RESPONSE 3.4. RE-ADV . 4. Protocol state machines 4.1 Media Consumer's state machine 4.2 Media Provider's state machine 5. Message Sequencing 6. Message Schema 7. CLUE protocol XML schema extensibility and versioning 7.1. Aspect 1 - new information within existing messages 7.2. Aspect 2 - new messages 8. Examples 9. Message Transport 10. Message Framing ...other stuff like Security considerations, IANA, etc. If folks could share their thoughts and opinions on this so we can get things moving forward, that would be great. Ideally, if we follow this approach, finding a new editor for the WG signaling document won't seem to be such an onerous task. Regards, Mary. --001a11c2cd7859dcb304e69760cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
HI all,

The diagram I presented is incl= uded in the proceedings in the chair charts (slide 7): =A0=A0Agenda & Status (Chairs)

The motivation for this suggestion is that we already h= ave another individual doc that is describing details of the CLUE protocol.= =A0I believe that keeping all the details of that in a separate document w= ill make the work more manageable. Otherwise, I fear we will have one of th= ose 200 page monster documents, which is difficult to share amongst multipl= e authors and a nightmare to progress. =A0 Even with this split, my guess i= s that both these documents would be anywhere from 75-100 pages when comple= ted once we get all the details in, including error handling, IANA registra= tions, security, etc.=A0

So, here is my suggestion for the Abstract/Intro = and ToC for the signaling document:
OLD Abstract:
This document specifies how signaling is conducted = in the course of CLUE sessions. This i= ncludes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol= that complements SIP/SDP and supports = negotiation of CLUE application level d= ata.

NEW Abstract:
=
This document specifies the signaling mod= el for CLUE sessions. It describes the= orchestration of SIP/SDP O/A with the CLUE protocol to support the=A0
CLUE use cases. This document identifies the SDP=A0
and RTP building blocks required to estab= lish a CLUE session.

New ToC:
1. Introduction =A0
2. Terminology  
3. Overview
This document describes the orchestration of the SIP SDP O/A signaling w=
ith the CLUE protocol [reference].   The details of the SDP and RTP buildin=
g blocks are also identified, with relevant references to the documents tha=
t are required for the overall CLUE solution. The document provides details=
 on the mapping that is required between constructs in the CLUE Data model =
[ref] and SDP.  This document also discusses how CLUE would operate in an e=
nvironment where one or more of the participants does not support CLUE.  A =
few examples are provided.  A separate document provides additional detaile=
d call flows of the realization of the CLUE use cases based upon the protoc=
ol details defined in this document. 
--- A nice diagram=
 would also help.  [In my opinion, this is a better place to introduce all =
the CLUE solution work, which I previously suggested should be in the Frame=
work.]
4.  CLUE use of SD=
P O/A 
  =
  4.1.  Establishing the CLUE channel=20
    4.2.  Representing CLUE Encodings in SDP=20
    4.3.  Representing CLUE Encoding Groups in SDP =20
    4.4.  Signaling CLUE control of "m" lines=20
     4.5.  Ensuring interoperability with non-CLUE devices=A0
5.  Interaction of CLUE an=
d SDP negotiations =20
     5.1 Independence of SDP and CLUE negotiation =20
     5.2.  Recommendations for operating with non-atomic operations  =20
     5.3.  Constraints on sending media
 =20
6.  Example: A call between two CLUE-capable endpoints =20

7.  Exam=
ple: A call between a CLUE and non-CLUE-capable endpoint   38
8.  CLUE requirements on S=
DP O/A =A0
9.  SIP Signaling=
=A0
10. Inter=
operation with non-CLUE aware SIP Devices [I'd rather ditch the term &q=
uot;legacy"]=A0
11. CLUE over RTCW=
EB=A0
....rem=
ainder is the same....
Here's the suggestion for the Abstract/Intro a=
nd ToC for the CLUE protocol document:
Th= is document provides the details for the CLUE protocol based upon the const= ructs defined in the CLUE framework. =A0The CLUE protocol is used in conjun= ction with SIP/SDP to establish CLUE sessions to support the CLUE use cases= . =A0The CLUE protocol is based on an XML schema that provides versioning a= nd extensibility. The CLUE pr= otocol carries CLUE information, as identified in the framework, in the for= m of XML documents and fragments conforming to the CLUE data model schema. =

Toc: = 
1. Introduction=A0
2.  =
Terminology
3.  Overview of the CLUE protocol messages=20
     3.1.  ADVERTISEMENT =20
     3.2.  CONFIGURE=20
     3.3.  RESPONSE=20
     3.4.  RE-ADV .
4.  Protocol state machines=20
    4.1 Media Consumer's state machine=20
    4.2 Media Provider's state machine
5.  Message Sequencing=A0=

<=
font class=3D"Apple-style-span" face=3D"arial, helvetica, sans-serif">6. =
=A0Message Schema
7.  =
CLUE protocol XML schema extensibility and versioning 
     7.1.  Aspect 1 - new information within existing messages =20
     7.2.  Aspect 2 - new messages 
8.  Examples
9.  Message Transport 
10. =
 Message Framing
...other stuff like Security considerations, IANA, =
etc.
If folks could share their thoughts and opinions on this = so we can get things moving forward, that would be great. =A0Ideally, if we= follow this approach, finding a new editor for the WG signaling document w= on't seem to be such an onerous task. =A0

Regards,
Mary.=A0
--001a11c2cd7859dcb304e69760cf-- From mary.ietf.barnes@gmail.com Tue Sep 17 11:07:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9822D11E812B for ; Tue, 17 Sep 2013 11:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.604 X-Spam-Level: X-Spam-Status: No, score=-101.604 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEwIIl8Wr1fF for ; Tue, 17 Sep 2013 11:07:07 -0700 (PDT) Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id BBD7411E82AC for ; Tue, 17 Sep 2013 11:06:27 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id nd7so4015562qeb.35 for ; Tue, 17 Sep 2013 11:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tT6KO24Fkc8K7y6eTf6PUOlfZZqWNrkCHisjj3jUZRk=; b=zee0LdG5TBue9k1Kp05E6f6nvhHudHaND8rPz3Sc84wvFlrgxjg6vJVDLrBtq/yqZn xrUZS06tEZdnYxDcmKquHD2gI1nfBDyx1YWIEByMUYvAwvL+NuVu3LorD7zrTq/vp6Vc dM9uBg+54aQlpX14LjKUzkEKDGioRQeuVQnfRIwFURgNs1/XI55OT5j3J36iglNMU58T l6bhlaqRQPNyGaGdZFNCt5jVj9wzCUfSARKFlG8p3d045NTBte26Is837GgSKA9aLcNB BztyBFZFgHP7uicQG4XX9zu0u2xTp5QKZuP9vQzzSoAG2pCaCPIEx3/gwNQ6rApkTtyf XioA== MIME-Version: 1.0 X-Received: by 10.224.163.12 with SMTP id y12mr8667591qax.92.1379441187057; Tue, 17 Sep 2013 11:06:27 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 17 Sep 2013 11:06:26 -0700 (PDT) In-Reply-To: <5237D653.901@nteczone.com> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> Date: Tue, 17 Sep 2013 13:06:26 -0500 Message-ID: From: Mary Barnes To: Christian Groves Content-Type: multipart/alternative; boundary=089e0158b352f174c004e6982dd7 Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:07:14 -0000 --089e0158b352f174c004e6982dd7 Content-Type: text/plain; charset=ISO-8859-1 Hi Christian, Thanks for taking the time to review this. Comments/responses below [MB]. Mary. On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves < Christian.Groves@nteczone.com> wrote: > Hello, > > Here are my comments to the WGLC: > > 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a means > to identify > the extent of individual video captures in > three dimensions. > > Did we decide whether this was with respect to a "plane of interest" in 3 > dimensions? and/or a volume (i.e. incorporating a depth aspect) in 3 > dimensions? It probably would be good to clarify this in the requirements. > [MB] I don't know that this particular detail matters in the requirements document. [/MB] > > 2) General: At different places there are references to particular use > cases. However this doesn't appear to used consistently. e.g. Regmt-9 > regarding interoperability between endpoints using different numbers of > streams makes references to the heterogeneous use case. The heterogeneous > use cases mentions different bit rates etc, however Reqmts-8, 7 etc don't > mention the use case? It seems to me that if we include references to use > cases that we should be consistent. > [MB] Not all requirements can be mapped directly to use cases - e.g., 16, 17 & 18. In the cases, where they can, we probably should. The references are intended to informative. [/MB] > > 3) REQMT-12: Rather than say "..more than two " should we use > "..more than two endpoints". We don't have a definition for "site". > [MB] We don't have an explicit definition but it can certainly be derived from the context. We use "site" in several other places and just replacing that with endpoint in those cases won't work - e.g,. in Section 4: "If Alice and Bob are at different sites, Alice needs to tell Bob about the camera and sound equipment arrangement at her site so that Bob's receiver can create an accurate rendering of her site." That all said, I think we can replace the use of "site" in that requirement as that's consistent with all the other requirements. [/MB] > > 4) General: Do we need to have some text in the document that indicates > that there may be other unspecified requirements that may be implemented? > The framework has a number of attributes that aren't mentioned as part of > the requirements e.g. scene description. Or alternatively do we capture > this by adding a generic requirement regarding description of the content > of captures/scenes? The requirements are very focussed on spatial/render > aspects rather than information pertaining to the selection of captures. > [MB] I do not believe so. These are the bare bones requirements - if we don't have functionality to support these then we haven't done our job. However, the solution can certainly define additional functionality, that doesn't necessarily map to a specific requirement. The requirements should not be specifying all the details of the attributes necessary to support the use cases - that's the objective of the framework. Now, if you think there is a general requirement that's missing, certainly you can propose such. Realistically, requirements documents are starting points to seed the solution work. Once the solution is started unless the WG thinks a requirement can't be met, it's not necessarily productive to try to make the requirements document absolutely complete. Indeed, a number of WGs actually never publish requirements documents, but rather just cache them in an appendix for historical purposes. [/MB] > > 5) General: There seems to be a requirement in CLUE of the ability to > indicate how captures are related to resources. e.g. the STS mechanism > indicates which captures may be used together (which indicates which ones > can't be used together) and the CSE that groups capture resources. This > seems to be an important aspect of CLUE but there doesn't appear to be a > requirement driving it. > [MB] As I mentioned previously, we don't need to have a requirement to justify every aspect of the solution. We don't want to get into having to define capture scene entries, etc. in the requirements. We don't need to backwards engineer the requirements to match the solution. [/MB] > > Regards, Christian > > > On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > >> We started WGLC on the requirements two weeks ago. >> It has run for two weeks, and there have been *NO* comments!!! :-( >> >> I can't advance this document without better indication of support from >> the WG. So I'm extending this WGLC. I'll be away next weekend, so I will >> let this extension run another two weeks, ending Sunday Sept 29. >> >> We NEED NEED NEED your comments on this. Please review it again, and >> respond either positively or negatively, whether you think it is ready to >> progress. >> >> Thanks, >> Paul >> >> On 9/2/13 3:50 PM, Paul Kyzivat wrote: >> >>> With this message I'm announcing the start of WGLC for >>> draft-ietf-clue-telepresence-**requirements-05 >>> >>> This WGLC will last for roughly two weeks, ending at midnight GMT on >>> Sunday September 15. >>> >>> It is important to have decisive results from a WGLC. >>> (Silence doesn't do it.) >>> So please, take a last careful look at these requirements and comment. >>> If you like these as they are, please say so. >>> >>> Thanks, >>> Paul (as co-chair) >>> >>> On 8/30/13 6:39 PM, internet-drafts@ietf.org wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the ControLling mUltiple streams for >>>> tElepresence Working Group of the IETF. >>>> >>>> Title : Requirements for Telepresence Multi-Streams >>>> Author(s) : Allyn Romanow >>>> Stephen Botzko >>>> Mary Barnes >>>> Filename : draft-ietf-clue-telepresence-** >>>> requirements-05.txt >>>> Pages : 13 >>>> Date : 2013-08-30 >>>> >>>> Abstract: >>>> This memo discusses the requirements for a specification that >>>> enables >>>> telepresence interoperability, by describing the relationship >>>> between >>>> multiple RTP streams. In addition, the problem statement and >>>> definitions are also covered herein. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/**doc/draft-ietf-clue-** >>>> telepresence-requirements >>>> >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/**draft-ietf-clue-telepresence-** >>>> requirements-05 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?**url2=draft-ietf-clue-** >>>> telepresence-requirements-05 >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-**drafts/ >>>> >>>> ______________________________**_________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/clue >>>> >>>> >>> ______________________________**_________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/**listinfo/clue >>> >>> >> ______________________________**_________________ >> 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 > --089e0158b352f174c004e6982dd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Christian,

Thanks for taking the tim= e to review this. Comments/responses below [MB].

M= ary.


On = Mon, Sep 16, 2013 at 11:10 PM, Christian Groves <Christian.Gro= ves@nteczone.com> wrote:
Hello,

Here are my comments to the WGLC:

1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a means t= o identify
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the extent of individual= video captures in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0three dimensions.

Did we decide whether this was with respect to a "plane of interest&qu= ot; in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect) in= 3 dimensions? It probably would be good to clarify this in the requirement= s.
[MB] I don't know that this particular detail matters= in the requirements document. =A0[/MB]

2) General: At different places there are references to particular use case= s. However this doesn't appear to used consistently. e.g. Regmt-9 regar= ding interoperability between endpoints using different numbers of streams = makes references to the heterogeneous use case. The heterogeneous use cases= mentions different bit rates etc, however Reqmts-8, 7 etc don't mentio= n the use case? It seems to me that if we include references to use cases t= hat we should be consistent.
[MB] Not all requirements can be mapped directly to use c= ases - e.g., 16, 17 & 18. In the cases, where they can, we probably sho= uld. The references are intended to informative. [/MB]

3) REQMT-12: Rather than say "..more than two <sites>" shou= ld we use "..more than two endpoints". We don't have a defini= tion for "site".
[MB] We don't have an e= xplicit definition but it can certainly be derived from the context. We use= "site" in several other places and just replacing that with endp= oint in those cases won't work - e.g,. in Section 4: =A0"If Alice and Bob are at different sites, Alice needs to= tell Bob about the cam= era and sound equipment arrangement at her site so that Bob's receiver can create an accurate= rendering of her site."
That all said, I think we can replace the use of "site" in= that requirement as that's consistent with all the other requirements.=
[/MB]

4) General: Do we need to have some text in the document that indicates tha= t there may be other unspecified requirements that may be implemented? The = framework has a number of attributes that aren't mentioned as part of t= he requirements e.g. scene description. Or alternatively do we capture this= by adding a generic requirement regarding description of the content of ca= ptures/scenes? The requirements are very focussed on spatial/render aspects= rather than information pertaining to the selection of captures.
[MB] I do not believe so. =A0These are the bare bones req= uirements - if we don't have functionality to support these then we hav= en't done our job. =A0However, the solution can certainly define additi= onal functionality, that doesn't necessarily map to a specific requirem= ent. =A0The requirements should not be specifying all the details of the at= tributes necessary to support the use cases - that's the objective of t= he framework. Now, if you think there is a general requirement that's m= issing, certainly you can propose such. Realistically, requirements documen= ts are starting points to seed the solution work. Once the solution is star= ted unless the WG thinks a requirement can't be met, it's not neces= sarily productive to try to make the requirements document absolutely compl= ete. =A0Indeed, a number of WGs actually never publish requirements documen= ts, but rather just cache them in an appendix for historical purposes. [/MB= ]

5) General: There seems to be a requirement in CLUE of the ability to indic= ate how captures are related to resources. e.g. the STS mechanism indicates= which captures may be used together (which indicates which ones can't = be used together) and the CSE that groups capture resources. This seems to = be an important aspect of CLUE but there doesn't appear to be a require= ment driving it.
[MB] As I mentioned previously, we don't need to have= a requirement to justify every aspect of the solution. =A0 We don't wa= nt to get into having to define capture scene entries, etc. in the requirem= ents. =A0 We don't need to backwards engineer the requirements to match= the solution. =A0[/MB]

Regards, Christian


On 16/09/2013 5:32 AM, Paul Kyzivat wrote:
We started WGLC on the requirements two weeks ago.
It has run for two weeks, and there have been *NO* comments!!! :-(

I can't advance this document without better indication of support from= the WG. So I'm extending this WGLC. I'll be away next weekend, so = I will let this extension run another two weeks, ending Sunday Sept 29.

We NEED NEED NEED your comments on this. Please review it again, and respon= d either positively or negatively, whether you think it is ready to progres= s.

=A0 =A0 Thanks,
=A0 =A0 Paul

On 9/2/13 3:50 PM, Paul Kyzivat wrote:
With this message I'm announcing the start of WGLC for
draft-ietf-clue-telepresence-requirements-05

This WGLC will last for roughly two weeks, ending at midnight GMT on
Sunday September 15.

It is important to have decisive results from a WGLC.
(Silence doesn't do it.)
So please, take a last careful look at these requirements and comment.
If you like these as they are, please say so.

=A0 =A0 =A0Thanks,
=A0 =A0 =A0Paul (as co-chair)

On 8/30/13 6:39 PM, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
=A0 This draft is a work item of the ControLling mUltiple streams for
tElepresence Working Group of the IETF.

=A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for Telepresence Multi-Str= eams
=A0 =A0 Author(s) =A0 =A0 =A0 : Allyn Romanow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stephen Botzko
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mary Barnes
=A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-clue-telepresence-requi= rements-05.txt
=A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 13
=A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-08-30

Abstract:
=A0 =A0 This memo discusses the requirements for a specification that enabl= es
=A0 =A0 telepresence interoperability, by describing the relationship betwe= en
=A0 =A0 multiple RTP streams. =A0In addition, the problem statement and
=A0 =A0 definitions are also covered herein.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft= -ietf-clue-telepresence-requirements


There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-clu= e-telepresence-requirements-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-clue-telepresence-requirements-05



Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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


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


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


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

--089e0158b352f174c004e6982dd7-- From mary.ietf.barnes@gmail.com Tue Sep 17 11:14:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D215411E8135 for ; Tue, 17 Sep 2013 11:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.397 X-Spam-Level: X-Spam-Status: No, score=-102.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7iV3qJg4xkV for ; Tue, 17 Sep 2013 11:14:41 -0700 (PDT) Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1B711E8133 for ; Tue, 17 Sep 2013 11:14:41 -0700 (PDT) Received: by mail-qe0-f44.google.com with SMTP id 3so4022831qeb.3 for ; Tue, 17 Sep 2013 11:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=87tpXqoXu+pkawVGuFFdtc/vZMDfAEcAS46bprRK6YU=; b=IzZ/PWbAkB7WOSOIt7f3cQjGu3qp0GPVulMpQ1XjkNYRjZxAS6DClqZ3oiMemvyVW/ +ZsWJCCxJQEFZExSSGLGDXNSH1DygQ26GMPRZUSVe8RZ2zutAUEC/+TGe1Sme3e7/8vn jKEbm2o+l/V3Wr+6Cxk5MMrTb+DeBxlPHM6ejr+i+ceQQfXAvww81cy0zupSWz32FlOB 9V93BMCtuyiuwpyseXXPk4QhGItqM8vLB1KoQAx7+S7P/ba1Jbiq3xknUzBAl2b2Ya+T BJYUZI5VozWYBgbGIxnVKbkR6iKEpacH72dg9WYYsoDVWs/XUj9C4NaBhXmswBgIcobE oWaQ== MIME-Version: 1.0 X-Received: by 10.224.73.137 with SMTP id q9mr5267338qaj.96.1379441680715; Tue, 17 Sep 2013 11:14:40 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 17 Sep 2013 11:14:40 -0700 (PDT) Date: Tue, 17 Sep 2013 13:14:40 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=001a11c3bed45e180004e6984b53 Subject: [clue] IETF-88 Deadlines X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 17 Sep 2013 18:14:41 -0000 --001a11c3bed45e180004e6984b53 Content-Type: text/plain; charset=ISO-8859-1 Note, there was a typo in the chair charts with regards to IETF-88 deadlines (I've uploaded a revision to fix that). Please note that there is a single draft deadline - that is Monday, October 21st @24:00 UTC. That is about 4.5 weeks away. Regards, Mary. --001a11c3bed45e180004e6984b53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Note, there was a typo in the chair charts with regards to= IETF-88 deadlines (I've uploaded a revision to fix that).

Please note that there is a single draft deadline - that is Monday, = October 21st @24:00 UTC. =A0That is about 4.5 weeks away. =A0

Regards,
Mary.
--001a11c3bed45e180004e6984b53-- From pkyzivat@alum.mit.edu Tue Sep 17 13:29:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF711E8196 for ; Tue, 17 Sep 2013 13:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obTrCHPQG+AW for ; Tue, 17 Sep 2013 13:28:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id B0AFD11E857D for ; Tue, 17 Sep 2013 13:28:48 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id SBtE1m0050ldTLk53LUd8x; Tue, 17 Sep 2013 20:28:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id SLUd1m00e3ZTu2S01LUdMy; Tue, 17 Sep 2013 20:28:37 +0000 Message-ID: <5238BB74.6090907@alum.mit.edu> Date: Tue, 17 Sep 2013 16:28:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379449717; bh=JVuhwBtwVDmLVoaPC/wsn9G4KnAGUHbyyINuKjRLZOM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DJLQn1n99j/vFs15G9D9fCMvyyEhamq7PLN+1b4AiDpxgZ734BkHeTIBgDxjl0dar cKpZvvMA9/zq/GRzIEA7fzK0mTdhwv9GAm/A+/2z84AnXchwI7JvUfan8V4XGdv1aL J10boVDfYgEYLZnnMQuu7FkcRbFW3AZbMgFDwDNPyxgTODzqy4tEYRlZA0dhaqzgCS y+TCotZoCUyAoKHNvRASgfs266KUodDS2tmIUFyRcf3Ve6znkCrABPmULIEcNMajj0 fjJejeltUfCvudC5SbOZyvjCgvPEw/zYkW9EnqjUnkZZnqNv79dhe+XBSw9AHVF8p9 8shE6mvEWAFIQ== Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 20:29:01 -0000 Mary, IIUC, you are proposing to make a change from "site" to "endpoint" in Reqmnt-12, and otherwise leave things alone? Thanks, Paul On 9/17/13 2:06 PM, Mary Barnes wrote: > Hi Christian, > > Thanks for taking the time to review this. Comments/responses below [MB]. > > Mary. > > > On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > > > wrote: > > Hello, > > Here are my comments to the WGLC: > > 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a > means to identify > the extent of individual video captures in > three dimensions. > > Did we decide whether this was with respect to a "plane of interest" > in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect) > in 3 dimensions? It probably would be good to clarify this in the > requirements. > > [MB] I don't know that this particular detail matters in the > requirements document. [/MB] > > > 2) General: At different places there are references to particular > use cases. However this doesn't appear to used consistently. e.g. > Regmt-9 regarding interoperability between endpoints using different > numbers of streams makes references to the heterogeneous use case. > The heterogeneous use cases mentions different bit rates etc, > however Reqmts-8, 7 etc don't mention the use case? It seems to me > that if we include references to use cases that we should be consistent. > > [MB] Not all requirements can be mapped directly to use cases - e.g., > 16, 17 & 18. In the cases, where they can, we probably should. The > references are intended to informative. [/MB] > > > 3) REQMT-12: Rather than say "..more than two " should we use > "..more than two endpoints". We don't have a definition for "site". > > [MB] We don't have an explicit definition but it can certainly be > derived from the context. We use "site" in several other places and just > replacing that with endpoint in those cases won't work - e.g,. in > Section 4: "If Alice and Bob are at different sites, Alice needs to > tell Bob about the camera and sound equipment arrangement at her site so > that Bob's receiver can create an accurate rendering of her site." > That all said, I think we can replace the use of "site" in that > requirement as that's consistent with all the other requirements. > [/MB] > > > 4) General: Do we need to have some text in the document that > indicates that there may be other unspecified requirements that may > be implemented? The framework has a number of attributes that aren't > mentioned as part of the requirements e.g. scene description. Or > alternatively do we capture this by adding a generic requirement > regarding description of the content of captures/scenes? The > requirements are very focussed on spatial/render aspects rather than > information pertaining to the selection of captures. > > [MB] I do not believe so. These are the bare bones requirements - if we > don't have functionality to support these then we haven't done our job. > However, the solution can certainly define additional functionality, > that doesn't necessarily map to a specific requirement. The > requirements should not be specifying all the details of the attributes > necessary to support the use cases - that's the objective of the > framework. Now, if you think there is a general requirement that's > missing, certainly you can propose such. Realistically, requirements > documents are starting points to seed the solution work. Once the > solution is started unless the WG thinks a requirement can't be met, > it's not necessarily productive to try to make the requirements document > absolutely complete. Indeed, a number of WGs actually never publish > requirements documents, but rather just cache them in an appendix for > historical purposes. [/MB] > > > 5) General: There seems to be a requirement in CLUE of the ability > to indicate how captures are related to resources. e.g. the STS > mechanism indicates which captures may be used together (which > indicates which ones can't be used together) and the CSE that groups > capture resources. This seems to be an important aspect of CLUE but > there doesn't appear to be a requirement driving it. > > [MB] As I mentioned previously, we don't need to have a requirement to > justify every aspect of the solution. We don't want to get into having > to define capture scene entries, etc. in the requirements. We don't > need to backwards engineer the requirements to match the solution. [/MB] > > > Regards, Christian > > > On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* comments!!! :-( > > I can't advance this document without better indication of > support from the WG. So I'm extending this WGLC. I'll be away > next weekend, so I will let this extension run another two > weeks, ending Sunday Sept 29. > > We NEED NEED NEED your comments on this. Please review it again, > and respond either positively or negatively, whether you think > it is ready to progress. > > Thanks, > Paul > > On 9/2/13 3:50 PM, Paul Kyzivat wrote: > > With this message I'm announcing the start of WGLC for > draft-ietf-clue-telepresence-__requirements-05 > > This WGLC will last for roughly two weeks, ending at > midnight GMT on > Sunday September 15. > > It is important to have decisive results from a WGLC. > (Silence doesn't do it.) > So please, take a last careful look at these requirements > and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) > > On 8/30/13 6:39 PM, internet-drafts@ietf.org > wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts > directories. > This draft is a work item of the ControLling mUltiple > streams for > tElepresence Working Group of the IETF. > > Title : Requirements for Telepresence > Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : > draft-ietf-clue-telepresence-__requirements-05.txt > Pages : 13 > Date : 2013-08-30 > > Abstract: > This memo discusses the requirements for a > specification that enables > telepresence interoperability, by describing the > relationship between > multiple RTP streams. In addition, the problem > statement and > definitions are also covered herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements > > > > > There's also a htmlized version available at: > http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05 > > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?__url2=draft-ietf-clue-__telepresence-requirements-05 > > > > > > Please note that it may take a couple of minutes from > the time of > submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-__drafts/ > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Sep 17 14:00:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D02C11E832E for ; Tue, 17 Sep 2013 14:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbZ1zYIz9nbf for ; Tue, 17 Sep 2013 14:00:10 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 1644611E810A for ; Tue, 17 Sep 2013 14:00:09 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id SKsn1m0031ei1Bg53M09sa; Tue, 17 Sep 2013 21:00:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id SM081m0183ZTu2S3kM087z; Tue, 17 Sep 2013 21:00:09 +0000 Message-ID: <5238C2D7.4020200@alum.mit.edu> Date: Tue, 17 Sep 2013 17:00:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379451609; bh=yoxE7Ie+AH6JNfxxzwaVM3MekHMEuWc7quy4dcDXYZw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SULhoifdEdGHrcOTUDEjLF0mduvDVzw+gAXgUebtunm9pN0sluXB4itAk+AptYfWG zvLegdt2PWEIGqZQ7VTpB4BzAtHkfPVvOmkVtbP1+SYtJuGwAzUWKuMy9RjkmlHYti asZKgK4zyiLAsuh2HhWF8cQ+dWY+2DiKjv76xjQ4GgaAnHk/WcZ3Yqb0F/9MhGA15l YuoyoASov5l1LNUOBX2EbAGcuTWQf14esWtXTbqKpJtPg5BoRkyQRNrZOMtIeWTYoF bwaMlCjW6krvNSpRP45qM5S28L3GdVnZOiXA+Kr/aFFZONbqmW1EFNL1v+iTVfktYA IJjsPd2XUi5DQ== Cc: CLUE Subject: Re: [clue] Proposal for dividing and restructuring Signaling work. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:00:15 -0000 Mary, I do agree the clue protocol can be a separate document, as long as the cut is done cleanly. I think that means it includes all the messages, defined as XML elements that are exchanged over a single reliable bidirectional medium, along with their semantics and sequencing. The signaling document will then define how they are transported. There will need to be a defined interface: the errors that might occur when sending or receiving messages that the protocol needs to cope with, and maybe some action(s) to reset/retry the transport. That would, in principle, allow the protocol to be rehosted over some other transport, though we have no specific plans to do that. More comments on the rest later. Thanks, Paul On 9/17/13 1:08 PM, Mary Barnes wrote: > HI all, > > The diagram I presented is included in the proceedings in the chair > charts (slide 7): Agenda & Status (Chairs) > > > The motivation for this suggestion is that we already have another > individual doc that is describing details of the CLUE protocol. I > believe that keeping all the details of that in a separate document will > make the work more manageable. Otherwise, I fear we will have one of > those 200 page monster documents, which is difficult to share amongst > multiple authors and a nightmare to progress. Even with this split, my > guess is that both these documents would be anywhere from 75-100 pages > when completed once we get all the details in, including error handling, > IANA registrations, security, etc. > > So, here is my suggestion for the Abstract/Intro and ToC for the > signaling document: > OLD Abstract: > This document specifies how signaling is conducted in the course of CLUE > sessions. This includes how SIP/SDP signaling is applied to CLUE > sessions as well as defining a CLUE-specific signaling protocol that > complements SIP/SDP and supports negotiation of CLUE application level data. > > NEW Abstract: > This document specifies the signaling model for CLUE sessions. It > describes the orchestration of SIP/SDP O/A with the CLUE protocol to > support the > CLUE use cases. This document identifies the SDP > and RTP building blocks required to establish a CLUE session. > > New ToC: > > 1. Introduction > > 2. Terminology > > 3. Overview > > This document describes the orchestration of the SIP SDP O/A signaling with the CLUE protocol [reference]. The details of the SDP and RTP building blocks are also identified, with relevant references to the documents that are required for the overall CLUE solution. The document provides details on the mapping that is required between constructs in the CLUE Data model [ref] and SDP. This document also discusses how CLUE would operate in an environment where one or more of the participants does not support CLUE. A few examples are provided. A separate document provides additional detailed call flows of the realization of the CLUE use cases based upon the protocol details defined in this document. > > --- A nice diagram would also help. [In my opinion, this is a better place to introduce all the CLUE solution work, which I previously suggested should be in the Framework.] > > 4. CLUE use of SDP O/A > > 4.1. Establishing the CLUE channel > 4.2. Representing CLUE Encodings in SDP > 4.3. Representing CLUE Encoding Groups in SDP > 4.4. Signaling CLUE control of "m" lines > 4.5. Ensuring interoperability with non-CLUE devices > > 5. Interaction of CLUE and SDP negotiations > 5.1 Independence of SDP and CLUE negotiation > 5.2. Recommendations for operating with non-atomic operations > 5.3. Constraints on sending media > > > 6. Example: A call between two CLUE-capable endpoints > > 7. Example: A call between a CLUE and non-CLUE-capable endpoint 38 > > 8. CLUE requirements on SDP O/A > > 9. SIP Signaling > > 10. Interoperation with non-CLUE aware SIP Devices [I'd rather ditch the term "legacy"] > > 11. CLUE over RTCWEB > > ....remainder is the same.... > > Here's the suggestion for the Abstract/Intro and ToC for the CLUE protocol document: > > This document provides the details for the CLUE protocol based upon the > constructs defined in the CLUE framework. The CLUE protocol is used in > conjunction with SIP/SDP to establish CLUE sessions to support the CLUE > use cases. The CLUE protocol is based on an XML schema that provides > versioning and extensibility. The CLUE protocol carries CLUE > information, as identified in the framework, in the form of XML > documents and fragments conforming to the CLUE data model schema. > > Toc: > > 1. Introduction > > 2. Terminology > > 3. Overview of the CLUE protocol messages > 3.1. ADVERTISEMENT > 3.2. CONFIGURE > 3.3. RESPONSE > 3.4. RE-ADV . > 4. Protocol state machines > 4.1 Media Consumer's state machine > 4.2 Media Provider's state machine > > 5. Message Sequencing > > 6. Message Schema > > 7. CLUE protocol XML schema extensibility and versioning > > 7.1. Aspect 1 - new information within existing messages > 7.2. Aspect 2 - new messages > > 8. Examples > > 9. Message Transport > > 10. Message Framing > > ...other stuff like Security considerations, IANA, etc. > > If folks could share their thoughts and opinions on this so we can get > things moving forward, that would be great. Ideally, if we follow this > approach, finding a new editor for the WG signaling document won't seem > to be such an onerous task. > > Regards, > Mary. From mary.ietf.barnes@gmail.com Tue Sep 17 14:04:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4DA11E847F for ; Tue, 17 Sep 2013 14:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.557 X-Spam-Level: X-Spam-Status: No, score=-101.557 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYOwYDFMWY6b for ; Tue, 17 Sep 2013 14:04:07 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id CC94511E831B for ; Tue, 17 Sep 2013 14:04:06 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c9so4041421qcz.0 for ; Tue, 17 Sep 2013 14:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BfvcfM/rEthigGf3RmIYARkc9mHDxGBlhUGpiMA6U5Y=; b=EC7SKsWf2xIalXXqnop2HY22DA9cTZkmdWetaf6u1StPkHf4gHcP3Xhfgai+KqCuZz 6SAIuvT1p6BNYHBfgjPaOJC8xB6O6NujvxdYaFO8UwzCaGeqKHS1mGL5L1n9HqtQYhxk wFVRHuKTJcdAga+7rkbPM03nlXehQCOK2UIaD/IT5RskRj3aBaM+6X9wvjmPAnnGeh8v XquzVxuNHEc6YaPTl+g5YV+c4l8GWguA2JFnLtSANqPJBHsvORACwDeyQEP/HlNmqx70 zrxGupfx8YTxbhv+4vubjRjsKnbDH5r5x58WeAhqpw9Tp/TBZY3h+Q2Mw+WdR9ZclL1G /dWQ== MIME-Version: 1.0 X-Received: by 10.224.163.12 with SMTP id y12mr9808507qax.92.1379451845225; Tue, 17 Sep 2013 14:04:05 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 17 Sep 2013 14:04:05 -0700 (PDT) In-Reply-To: <5238BB74.6090907@alum.mit.edu> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <5238BB74.6090907@alum.mit.edu> Date: Tue, 17 Sep 2013 16:04:05 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=089e0158b35238352f04e69aa9f6 Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:04:08 -0000 --089e0158b35238352f04e69aa9f6 Content-Type: text/plain; charset=ISO-8859-1 Yes. There are other requirements using the term site. If you look at the definition of "endpoint", there is the following statement: Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. So, I think we are using site to refer explicitly/only to multiscreen/multicamera rooms. Maybe the easiest thing to do is to just add a parenthetical comment in that sentence like the following: Endpoints can be anything from multiscreen/multicamera rooms (referred to as "sites") to handheld devices. Then, I do think it is appropriate to change the word "site" in REQMT-12 to "endpoint" as the intent of the requirement should also to endpoints other than multiscreen/multicamera rooms. I think the use of "site" in the other requirements is okay. Mary. On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat wrote: > Mary, > > IIUC, you are proposing to make a change from "site" to "endpoint" in > Reqmnt-12, and otherwise leave things alone? > > Thanks, > Paul > > > On 9/17/13 2:06 PM, Mary Barnes wrote: > >> Hi Christian, >> >> Thanks for taking the time to review this. Comments/responses below [MB]. >> >> Mary. >> >> >> On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves >> >> >> >> >> wrote: >> >> Hello, >> >> Here are my comments to the WGLC: >> >> 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a >> means to identify >> the extent of individual video captures in >> three dimensions. >> >> Did we decide whether this was with respect to a "plane of interest" >> in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect) >> in 3 dimensions? It probably would be good to clarify this in the >> requirements. >> >> [MB] I don't know that this particular detail matters in the >> requirements document. [/MB] >> >> >> 2) General: At different places there are references to particular >> use cases. However this doesn't appear to used consistently. e.g. >> Regmt-9 regarding interoperability between endpoints using different >> numbers of streams makes references to the heterogeneous use case. >> The heterogeneous use cases mentions different bit rates etc, >> however Reqmts-8, 7 etc don't mention the use case? It seems to me >> that if we include references to use cases that we should be >> consistent. >> >> [MB] Not all requirements can be mapped directly to use cases - e.g., >> 16, 17 & 18. In the cases, where they can, we probably should. The >> references are intended to informative. [/MB] >> >> >> 3) REQMT-12: Rather than say "..more than two " should we use >> "..more than two endpoints". We don't have a definition for "site". >> >> [MB] We don't have an explicit definition but it can certainly be >> derived from the context. We use "site" in several other places and just >> replacing that with endpoint in those cases won't work - e.g,. in >> Section 4: "If Alice and Bob are at different sites, Alice needs to >> tell Bob about the camera and sound equipment arrangement at her site so >> that Bob's receiver can create an accurate rendering of her site." >> That all said, I think we can replace the use of "site" in that >> requirement as that's consistent with all the other requirements. >> [/MB] >> >> >> 4) General: Do we need to have some text in the document that >> indicates that there may be other unspecified requirements that may >> be implemented? The framework has a number of attributes that aren't >> mentioned as part of the requirements e.g. scene description. Or >> alternatively do we capture this by adding a generic requirement >> regarding description of the content of captures/scenes? The >> requirements are very focussed on spatial/render aspects rather than >> information pertaining to the selection of captures. >> >> [MB] I do not believe so. These are the bare bones requirements - if we >> don't have functionality to support these then we haven't done our job. >> However, the solution can certainly define additional functionality, >> that doesn't necessarily map to a specific requirement. The >> requirements should not be specifying all the details of the attributes >> necessary to support the use cases - that's the objective of the >> framework. Now, if you think there is a general requirement that's >> missing, certainly you can propose such. Realistically, requirements >> documents are starting points to seed the solution work. Once the >> solution is started unless the WG thinks a requirement can't be met, >> it's not necessarily productive to try to make the requirements document >> absolutely complete. Indeed, a number of WGs actually never publish >> requirements documents, but rather just cache them in an appendix for >> historical purposes. [/MB] >> >> >> 5) General: There seems to be a requirement in CLUE of the ability >> to indicate how captures are related to resources. e.g. the STS >> mechanism indicates which captures may be used together (which >> indicates which ones can't be used together) and the CSE that groups >> capture resources. This seems to be an important aspect of CLUE but >> there doesn't appear to be a requirement driving it. >> >> [MB] As I mentioned previously, we don't need to have a requirement to >> justify every aspect of the solution. We don't want to get into having >> to define capture scene entries, etc. in the requirements. We don't >> need to backwards engineer the requirements to match the solution. [/MB] >> >> >> Regards, Christian >> >> >> On 16/09/2013 5:32 AM, Paul Kyzivat wrote: >> >> We started WGLC on the requirements two weeks ago. >> It has run for two weeks, and there have been *NO* comments!!! :-( >> >> I can't advance this document without better indication of >> support from the WG. So I'm extending this WGLC. I'll be away >> next weekend, so I will let this extension run another two >> weeks, ending Sunday Sept 29. >> >> We NEED NEED NEED your comments on this. Please review it again, >> and respond either positively or negatively, whether you think >> it is ready to progress. >> >> Thanks, >> Paul >> >> On 9/2/13 3:50 PM, Paul Kyzivat wrote: >> >> With this message I'm announcing the start of WGLC for >> draft-ietf-clue-telepresence-_**_requirements-05 >> >> >> This WGLC will last for roughly two weeks, ending at >> midnight GMT on >> Sunday September 15. >> >> It is important to have decisive results from a WGLC. >> (Silence doesn't do it.) >> So please, take a last careful look at these requirements >> and comment. >> If you like these as they are, please say so. >> >> Thanks, >> Paul (as co-chair) >> >> On 8/30/13 6:39 PM, internet-drafts@ietf.org >> > >> wrote: >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts >> directories. >> This draft is a work item of the ControLling mUltiple >> streams for >> tElepresence Working Group of the IETF. >> >> Title : Requirements for Telepresence >> Multi-Streams >> Author(s) : Allyn Romanow >> Stephen Botzko >> Mary Barnes >> Filename : >> draft-ietf-clue-telepresence-_**_requirements-05.txt >> >> Pages : 13 >> Date : 2013-08-30 >> >> Abstract: >> This memo discusses the requirements for a >> specification that enables >> telepresence interoperability, by describing the >> relationship between >> multiple RTP streams. In addition, the problem >> statement and >> definitions are also covered herein. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/_**_doc/draft-ietf-clue-__** >> telepresence-requirements >> >> > telepresence-requirements >> > >> >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/__** >> draft-ietf-clue-telepresence-_**_requirements-05 >> >> > draft-ietf-clue-telepresence-**requirements-05 >> > >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?__**url2=draft-ietf-clue-__** >> telepresence-requirements-05 >> >> > telepresence-requirements-05 >> > >> >> >> >> >> Please note that it may take a couple of minutes from >> the time of >> submission >> until the htmlized version and diff are available at >> tools.ietf.org . >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-__**drafts/ >> >> > >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> >> > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --089e0158b35238352f04e69aa9f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes. =A0There are other requirements using the term site. = =A0If you look at the definition of "endpoint", there is the foll= owing statement:=A0
=A0 =A0 =A0 =A0 =A0 =A0=A0Endpoints can be anything = from
multiscreen/multicamera rooms to handhel= d devices.

So, I think we are using site to= refer explicitly/only to=A0mu= ltiscreen/multicamera rooms. Maybe the easiest thing to do is to just add = a parenthetical comment in that sentence like the following:<= /div> 
      End=
points can be anything from
      multiscreen/multicamera rooms (referred to as "sites") to h=
andheld devices.
Then, I do think it is appropr= iate to change the word "site" in REQMT-12 to "endpoint"= ; as the intent of the requirement should also to endpoints other than mult= iscreen/multicamera rooms. =A0I think the use of "site" in the ot= her requirements is okay.=A0

Mary.=A0

On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzi= vat <pkyzivat@alum.mit.edu> wrote:
Mary,

IIUC, you are proposing to make a change from "site" to "end= point" in Reqmnt-12, and otherwise leave things alone?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 9/17/13 2:06 PM, Mary Barnes wrote:
Hi Christian,

Thanks for taking the time to review this. Comments/responses below [MB].
Mary.


On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves
<Chri= stian.Groves@nteczone.com <mailto:Christian.Groves@nteczone.com&g= t;>

wrote:

=A0 =A0 Hello,

=A0 =A0 Here are my comments to the WGLC:

=A0 =A0 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a=
=A0 =A0 means to identify
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the extent of i= ndividual video captures in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 three dimension= s.

=A0 =A0 Did we decide whether this was with respect to a "plane of int= erest"
=A0 =A0 in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect= )
=A0 =A0 in 3 dimensions? It probably would be good to clarify this in the =A0 =A0 requirements.

[MB] I don't know that this particular detail matters in the
requirements document. =A0[/MB]


=A0 =A0 2) General: At different places there are references to particular<= br> =A0 =A0 use cases. However this doesn't appear to used consistently. e.= g.
=A0 =A0 Regmt-9 regarding interoperability between endpoints using differen= t
=A0 =A0 numbers of streams makes references to the heterogeneous use case.<= br> =A0 =A0 The heterogeneous use cases mentions different bit rates etc,
=A0 =A0 however Reqmts-8, 7 etc don't mention the use case? It seems to= me
=A0 =A0 that if we include references to use cases that we should be consis= tent.

[MB] Not all requirements can be mapped directly to use cases - e.g.,
16, 17 & 18. In the cases, where they can, we probably should. The
references are intended to informative. [/MB]


=A0 =A0 3) REQMT-12: Rather than say "..more than two <sites>&qu= ot; should we use
=A0 =A0 "..more than two endpoints". We don't have a definiti= on for "site".

[MB] We don't have an explicit definition but it can certainly be
derived from the context. We use "site" in several other places a= nd just
replacing that with endpoint in those cases won't work - e.g,. in
Section 4: =A0"If Alice and Bob are at different sites, Alice needs to=
tell Bob about the camera and sound equipment arrangement at her site so that Bob's receiver can create an accurate rendering of her site."=
That all said, I think we can replace the use of "site" in that requirement as that's consistent with all the other requirements.
[/MB]


=A0 =A0 4) General: Do we need to have some text in the document that
=A0 =A0 indicates that there may be other unspecified requirements that may=
=A0 =A0 be implemented? The framework has a number of attributes that aren&= #39;t
=A0 =A0 mentioned as part of the requirements e.g. scene description. Or =A0 =A0 alternatively do we capture this by adding a generic requirement =A0 =A0 regarding description of the content of captures/scenes? The
=A0 =A0 requirements are very focussed on spatial/render aspects rather tha= n
=A0 =A0 information pertaining to the selection of captures.

[MB] I do not believe so. =A0These are the bare bones requirements - if we<= br> don't have functionality to support these then we haven't done our = job.
=A0 However, the solution can certainly define additional functionality, that doesn't necessarily map to a specific requirement. =A0The
requirements should not be specifying all the details of the attributes
necessary to support the use cases - that's the objective of the
framework. Now, if you think there is a general requirement that's
missing, certainly you can propose such. Realistically, requirements
documents are starting points to seed the solution work. Once the
solution is started unless the WG thinks a requirement can't be met, it's not necessarily productive to try to make the requirements documen= t
absolutely complete. =A0Indeed, a number of WGs actually never publish
requirements documents, but rather just cache them in an appendix for
historical purposes. [/MB]


=A0 =A0 5) General: There seems to be a requirement in CLUE of the ability<= br> =A0 =A0 to indicate how captures are related to resources. e.g. the STS
=A0 =A0 mechanism indicates which captures may be used together (which
=A0 =A0 indicates which ones can't be used together) and the CSE that g= roups
=A0 =A0 capture resources. This seems to be an important aspect of CLUE but=
=A0 =A0 there doesn't appear to be a requirement driving it.

[MB] As I mentioned previously, we don't need to have a requirement to<= br> justify every aspect of the solution. =A0 We don't want to get into hav= ing
to define capture scene entries, etc. in the requirements. =A0 We don't=
need to backwards engineer the requirements to match the solution. =A0[/MB]=


=A0 =A0 Regards, Christian


=A0 =A0 On 16/09/2013 5:32 AM, Paul Kyzivat wrote:

=A0 =A0 =A0 =A0 We started WGLC on the requirements two weeks ago.
=A0 =A0 =A0 =A0 It has run for two weeks, and there have been *NO* comments= !!! :-(

=A0 =A0 =A0 =A0 I can't advance this document without better indication= of
=A0 =A0 =A0 =A0 support from the WG. So I'm extending this WGLC. I'= ll be away
=A0 =A0 =A0 =A0 next weekend, so I will let this extension run another two<= br> =A0 =A0 =A0 =A0 weeks, ending Sunday Sept 29.

=A0 =A0 =A0 =A0 We NEED NEED NEED your comments on this. Please review it a= gain,
=A0 =A0 =A0 =A0 and respond either positively or negatively, whether you th= ink
=A0 =A0 =A0 =A0 it is ready to progress.

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

=A0 =A0 =A0 =A0 On 9/2/13 3:50 PM, Paul Kyzivat wrote:

=A0 =A0 =A0 =A0 =A0 =A0 With this message I'm announcing the start of W= GLC for
=A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-clue-telepresence-__requirements-= 05


=A0 =A0 =A0 =A0 =A0 =A0 This WGLC will last for roughly two weeks, ending a= t
=A0 =A0 =A0 =A0 =A0 =A0 midnight GMT on
=A0 =A0 =A0 =A0 =A0 =A0 Sunday September 15.

=A0 =A0 =A0 =A0 =A0 =A0 It is important to have decisive results from a WGL= C.
=A0 =A0 =A0 =A0 =A0 =A0 (Silence doesn't do it.)
=A0 =A0 =A0 =A0 =A0 =A0 So please, take a last careful look at these requir= ements
=A0 =A0 =A0 =A0 =A0 =A0 and comment.
=A0 =A0 =A0 =A0 =A0 =A0 If you like these as they are, please say so.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul (as co-chair)

=A0 =A0 =A0 =A0 =A0 =A0 On 8/30/13 6:39 PM, internet-drafts@ietf.org
=A0 =A0 =A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A New Internet-Draft is available from the = on-line
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Drafts
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 directories.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This draft is a work item of the Con= troLling mUltiple
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 streams for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tElepresence Working Group of the IETF.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Requ= irements for Telepresence
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Multi-Streams
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Allyn Ro= manow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 Stephen Botzko
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 draft-ietf-clue-telepresence-__requi= rements-05.txt

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 13 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 20= 13-08-30

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This memo discusses the requirem= ents for a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 specification that enables
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0telepresence interoperability, b= y describing the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 relationship between
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0multiple RTP streams. =A0In addi= tion, the problem
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 statement and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0definitions are also covered her= ein.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The IETF datatracker status page for this d= raft is:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://d= atatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requ= irements

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://d= atatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirem= ents>



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 There's also a htmlized version availab= le at:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http://tools= .ietf.org/html/__draft-ietf-clue-telepresence-__requirements-= 05

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http://tools= .ietf.org/html/draft-ietf-clue-telepresence-requirements-05>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A diff from the previous version is availab= le at:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresen= ce-requirements-05

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <http= ://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-r= equirements-05>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Please note that it may take a couple of mi= nutes from
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the time of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 submission
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 until the htmlized version and diff are ava= ilable at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 tools.ietf.org <http://tools.ietf.org>.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Internet-Drafts are also available by anony= mous FTP at:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-__drafts/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-drafts/&g= t;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ____________________________________= _____________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 clue@ietf.org <mailto:clue@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listi= nfo/clue
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listi= nfo/clue>


=A0 =A0 =A0 =A0 =A0 =A0 ____________________________________________= _____
=A0 =A0 =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 =A0 =A0 = clue@ietf.org <mailto:clue@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue=
=A0 =A0 =A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue= >


=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>=


=A0 =A0 _________________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>




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


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

--089e0158b35238352f04e69aa9f6-- From pkyzivat@alum.mit.edu Tue Sep 17 15:25:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316F811E81CF for ; Tue, 17 Sep 2013 15:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.366 X-Spam-Level: X-Spam-Status: No, score=-0.366 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-q3+uCV2WX6 for ; Tue, 17 Sep 2013 15:25:20 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8C211E81B4 for ; Tue, 17 Sep 2013 15:25:16 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta13.westchester.pa.mail.comcast.net with comcast id SN6y1m0031YDfWL5DNRFEV; Tue, 17 Sep 2013 22:25:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id SNRF1m01H3ZTu2S3gNRF4W; Tue, 17 Sep 2013 22:25:15 +0000 Message-ID: <5238D6CA.3080500@alum.mit.edu> Date: Tue, 17 Sep 2013 18:25:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <5238BB74.6090907@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379456715; bh=ee8J2f1pRmEMUF1ed1s/FF5gXzVU09Pm7rnRXZO3DOU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FstWf1f1ZzPWK2wYL67h26ReoLf6cdmxgXAsbZcHNUoiXCAlazzGzUchsYEJY8FUl HqxPWYIdqmsqTmLK/r+qvbffwF7gSWUfkdWlurE4Iv0klbi5KnaL1wB8G/9c6ocA9B bT4ycja3cPVJj9nSm4N5snbv/iiFoFDK6lI+z62Gjw1b5WuaPaqiUNTd7qalWPXX0s VMuGTHWBfmxi23tNamSON5Jxp855m3DGCmh1kHzO9JSkxR3SOdo1WBUvqAHgl+FLVW xt4wscydXIq6E5JgRGeuQgirdv4opVBFpq215wAHuOFLhrptiH3i7I4qapJxJ7B3li IoHVTPXmAhITw== Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 22:25:27 -0000 Mary, On 9/17/13 5:04 PM, Mary Barnes wrote: > Yes. There are other requirements using the term site. If you look at > the definition of "endpoint", there is the following statement: > Endpoints can be anything from > multiscreen/multicamera rooms to handheld devices. > > So, I think we are using site to refer explicitly/only to > multiscreen/multicamera rooms. Are we? I think even then we are really talking about endpoints, but with our design center biased towards multiscreen/multicamera rooms. E.g., when we are doing "site switching", a CLUE compatible cell phone is still going to be treated as a site, together with the telepresence "rooms" in the session. I'm not aware of *anything* that is specific to multiscreen/multicamera endpoints. > Maybe the easiest thing to do is to just > add a parenthetical comment in that sentence like the following: > > Endpoints can be anything from > multiscreen/multicamera rooms (referred to as "sites") to handheld devices. Wouldn't that confuse the definition of site switching? Thanks, Paul > Then, I do think it is appropriate to change the word "site" in REQMT-12 > to "endpoint" as the intent of the requirement should also to endpoints > other than multiscreen/multicamera rooms. I think the use of "site" in > the other requirements is okay. > Mary. > > > On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat > wrote: > > Mary, > > IIUC, you are proposing to make a change from "site" to "endpoint" > in Reqmnt-12, and otherwise leave things alone? > > Thanks, > Paul > > > On 9/17/13 2:06 PM, Mary Barnes wrote: > > Hi Christian, > > Thanks for taking the time to review this. Comments/responses > below [MB]. > > Mary. > > > On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > > >> > > wrote: > > Hello, > > Here are my comments to the WGLC: > > 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST > support a > means to identify > the extent of individual video > captures in > three dimensions. > > Did we decide whether this was with respect to a "plane of > interest" > in 3 dimensions? and/or a volume (i.e. incorporating a > depth aspect) > in 3 dimensions? It probably would be good to clarify this > in the > requirements. > > [MB] I don't know that this particular detail matters in the > requirements document. [/MB] > > > 2) General: At different places there are references to > particular > use cases. However this doesn't appear to used > consistently. e.g. > Regmt-9 regarding interoperability between endpoints using > different > numbers of streams makes references to the heterogeneous > use case. > The heterogeneous use cases mentions different bit rates etc, > however Reqmts-8, 7 etc don't mention the use case? It > seems to me > that if we include references to use cases that we should > be consistent. > > [MB] Not all requirements can be mapped directly to use cases - > e.g., > 16, 17 & 18. In the cases, where they can, we probably should. The > references are intended to informative. [/MB] > > > 3) REQMT-12: Rather than say "..more than two " > should we use > "..more than two endpoints". We don't have a definition for > "site". > > [MB] We don't have an explicit definition but it can certainly be > derived from the context. We use "site" in several other places > and just > replacing that with endpoint in those cases won't work - e.g,. in > Section 4: "If Alice and Bob are at different sites, Alice needs to > tell Bob about the camera and sound equipment arrangement at her > site so > that Bob's receiver can create an accurate rendering of her site." > That all said, I think we can replace the use of "site" in that > requirement as that's consistent with all the other requirements. > [/MB] > > > 4) General: Do we need to have some text in the document that > indicates that there may be other unspecified requirements > that may > be implemented? The framework has a number of attributes > that aren't > mentioned as part of the requirements e.g. scene > description. Or > alternatively do we capture this by adding a generic > requirement > regarding description of the content of captures/scenes? The > requirements are very focussed on spatial/render aspects > rather than > information pertaining to the selection of captures. > > [MB] I do not believe so. These are the bare bones requirements > - if we > don't have functionality to support these then we haven't done > our job. > However, the solution can certainly define additional > functionality, > that doesn't necessarily map to a specific requirement. The > requirements should not be specifying all the details of the > attributes > necessary to support the use cases - that's the objective of the > framework. Now, if you think there is a general requirement that's > missing, certainly you can propose such. Realistically, requirements > documents are starting points to seed the solution work. Once the > solution is started unless the WG thinks a requirement can't be met, > it's not necessarily productive to try to make the requirements > document > absolutely complete. Indeed, a number of WGs actually never publish > requirements documents, but rather just cache them in an > appendix for > historical purposes. [/MB] > > > 5) General: There seems to be a requirement in CLUE of the > ability > to indicate how captures are related to resources. e.g. the STS > mechanism indicates which captures may be used together (which > indicates which ones can't be used together) and the CSE > that groups > capture resources. This seems to be an important aspect of > CLUE but > there doesn't appear to be a requirement driving it. > > [MB] As I mentioned previously, we don't need to have a > requirement to > justify every aspect of the solution. We don't want to get > into having > to define capture scene entries, etc. in the requirements. We > don't > need to backwards engineer the requirements to match the > solution. [/MB] > > > Regards, Christian > > > On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* > comments!!! :-( > > I can't advance this document without better indication of > support from the WG. So I'm extending this WGLC. I'll > be away > next weekend, so I will let this extension run another two > weeks, ending Sunday Sept 29. > > We NEED NEED NEED your comments on this. Please review > it again, > and respond either positively or negatively, whether > you think > it is ready to progress. > > Thanks, > Paul > > On 9/2/13 3:50 PM, Paul Kyzivat wrote: > > With this message I'm announcing the start of WGLC for > draft-ietf-clue-telepresence-____requirements-05 > > > This WGLC will last for roughly two weeks, ending at > midnight GMT on > Sunday September 15. > > It is important to have decisive results from a WGLC. > (Silence doesn't do it.) > So please, take a last careful look at these > requirements > and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) > > On 8/30/13 6:39 PM, internet-drafts@ietf.org > > > wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts > directories. > This draft is a work item of the ControLling > mUltiple > streams for > tElepresence Working Group of the IETF. > > Title : Requirements for > Telepresence > Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : > > draft-ietf-clue-telepresence-____requirements-05.txt > > Pages : 13 > Date : 2013-08-30 > > Abstract: > This memo discusses the requirements for a > specification that enables > telepresence interoperability, by > describing the > relationship between > multiple RTP streams. In addition, the > problem > statement and > definitions are also covered herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requirements > > > > > > > > > There's also a htmlized version available at: > http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements-05 > > > > > > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requirements-05 > > > > > > > > > > Please note that it may take a couple of > minutes from > the time of > submission > until the htmlized version and diff are > available at > tools.ietf.org . > > > Internet-Drafts are also available by anonymous > FTP at: > ftp://ftp.ietf.org/internet-____drafts/ > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > > > > > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > From mary.ietf.barnes@gmail.com Tue Sep 17 16:21:17 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00811E8634 for ; Tue, 17 Sep 2013 16:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.528 X-Spam-Level: X-Spam-Status: No, score=-101.528 tagged_above=-999 required=5 tests=[AWL=-0.595, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqj-duamaa9W for ; Tue, 17 Sep 2013 16:21:12 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BE14311E85F9 for ; Tue, 17 Sep 2013 16:21:11 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id k15so2435802qaq.9 for ; Tue, 17 Sep 2013 16:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cYYvMut0J/eShYg79jEbplcmbhDylLz0dPV1dMAp1Kc=; b=UM8TbI2bRFlHizFzmbVrVCxoRdlbUUFMtIOaxwDGAtU+Tk0IhhOWXCrD6WRuXwu0Cv 7A+m9Gk47vGesRUniku5GYmw5XiP9c0AokMYjBaVnThyPsfeQKhS64P9rxtvXUraf1ED ekAqCPV7+ZeGCEs4HQk3qjy3i65rHfk0pTCpMr9C6u6ybXVyVTxoBsMKy+R2mWlZQM17 rGDEwUrDY4/QPHdpJZSILb0DLis/HVR4WEP6qEOE2qaw0nO1HT8jVfmAWLEpa/j8Znsb 9E9U1NZ/doQ1y4X6/RrRA/amyJqbjB+ugM8hmvgBLgpWTXR4RM5DRcj/TA9LIIVv5Wuk KOcA== MIME-Version: 1.0 X-Received: by 10.49.51.67 with SMTP id i3mr1505156qeo.8.1379460070000; Tue, 17 Sep 2013 16:21:10 -0700 (PDT) Received: by 10.49.71.243 with HTTP; Tue, 17 Sep 2013 16:21:09 -0700 (PDT) In-Reply-To: <5238D6CA.3080500@alum.mit.edu> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <5238BB74.6090907@alum.mit.edu> <5238D6CA.3080500@alum.mit.edu> Date: Tue, 17 Sep 2013 18:21:09 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bdc0b6e74510904e69c9315 Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 23:21:17 -0000 --047d7bdc0b6e74510904e69c9315 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat wrote: > Mary, > > > On 9/17/13 5:04 PM, Mary Barnes wrote: > >> Yes. There are other requirements using the term site. If you look at >> the definition of "endpoint", there is the following statement: >> Endpoints can be anything from >> multiscreen/multicamera rooms to handheld devices. >> >> So, I think we are using site to refer explicitly/only to >> multiscreen/multicamera rooms. >> > > Are we? I think even then we are really talking about endpoints, but with > our design center biased towards multiscreen/multicamera rooms. > E.g., when we are doing "site switching", a CLUE compatible cell phone is > still going to be treated as a site, together with the telepresence "rooms" > in the session. > [MB] Actually, we don't define "site" in the CLUE framework either (and the word appears 89 times in the use cases). So, maybe we *should* define site and leave most of the requirements alone. I think the word conveys the concept well and I think we lose something if we change to endpoint in many cases, which we should do consistently if we propose to do so in the requirements document. [/MB] > > I'm not aware of *anything* that is specific to multiscreen/multicamera > endpoints. > > Maybe the easiest thing to do is to just >> add a parenthetical comment in that sentence like the following: >> >> Endpoints can be anything from >> multiscreen/multicamera rooms (referred to as "sites") to handheld >> devices. >> > > Wouldn't that confuse the definition of site switching? > > Thanks, > Paul > > > Then, I do think it is appropriate to change the word "site" in REQMT-12 >> to "endpoint" as the intent of the requirement should also to endpoints >> other than multiscreen/multicamera rooms. I think the use of "site" in >> the other requirements is okay. >> > > Mary. >> >> >> On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat > **> wrote: >> >> Mary, >> >> IIUC, you are proposing to make a change from "site" to "endpoint" >> in Reqmnt-12, and otherwise leave things alone? >> >> Thanks, >> Paul >> >> >> On 9/17/13 2:06 PM, Mary Barnes wrote: >> >> Hi Christian, >> >> Thanks for taking the time to review this. Comments/responses >> below [MB]. >> >> Mary. >> >> >> On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves >> > >> > >> >> >> >> >>> >> >> wrote: >> >> Hello, >> >> Here are my comments to the WGLC: >> >> 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST >> support a >> means to identify >> the extent of individual video >> captures in >> three dimensions. >> >> Did we decide whether this was with respect to a "plane of >> interest" >> in 3 dimensions? and/or a volume (i.e. incorporating a >> depth aspect) >> in 3 dimensions? It probably would be good to clarify this >> in the >> requirements. >> >> [MB] I don't know that this particular detail matters in the >> requirements document. [/MB] >> >> >> 2) General: At different places there are references to >> particular >> use cases. However this doesn't appear to used >> consistently. e.g. >> Regmt-9 regarding interoperability between endpoints using >> different >> numbers of streams makes references to the heterogeneous >> use case. >> The heterogeneous use cases mentions different bit rates etc, >> however Reqmts-8, 7 etc don't mention the use case? It >> seems to me >> that if we include references to use cases that we should >> be consistent. >> >> [MB] Not all requirements can be mapped directly to use cases - >> e.g., >> 16, 17 & 18. In the cases, where they can, we probably should. The >> references are intended to informative. [/MB] >> >> >> 3) REQMT-12: Rather than say "..more than two " >> should we use >> "..more than two endpoints". We don't have a definition for >> "site". >> >> [MB] We don't have an explicit definition but it can certainly be >> derived from the context. We use "site" in several other places >> and just >> replacing that with endpoint in those cases won't work - e.g,. in >> Section 4: "If Alice and Bob are at different sites, Alice needs >> to >> tell Bob about the camera and sound equipment arrangement at her >> site so >> that Bob's receiver can create an accurate rendering of her site." >> That all said, I think we can replace the use of "site" in that >> requirement as that's consistent with all the other requirements. >> [/MB] >> >> >> 4) General: Do we need to have some text in the document that >> indicates that there may be other unspecified requirements >> that may >> be implemented? The framework has a number of attributes >> that aren't >> mentioned as part of the requirements e.g. scene >> description. Or >> alternatively do we capture this by adding a generic >> requirement >> regarding description of the content of captures/scenes? The >> requirements are very focussed on spatial/render aspects >> rather than >> information pertaining to the selection of captures. >> >> [MB] I do not believe so. These are the bare bones requirements >> - if we >> don't have functionality to support these then we haven't done >> our job. >> However, the solution can certainly define additional >> functionality, >> that doesn't necessarily map to a specific requirement. The >> requirements should not be specifying all the details of the >> attributes >> necessary to support the use cases - that's the objective of the >> framework. Now, if you think there is a general requirement that's >> missing, certainly you can propose such. Realistically, >> requirements >> documents are starting points to seed the solution work. Once the >> solution is started unless the WG thinks a requirement can't be >> met, >> it's not necessarily productive to try to make the requirements >> document >> absolutely complete. Indeed, a number of WGs actually never >> publish >> requirements documents, but rather just cache them in an >> appendix for >> historical purposes. [/MB] >> >> >> 5) General: There seems to be a requirement in CLUE of the >> ability >> to indicate how captures are related to resources. e.g. the >> STS >> mechanism indicates which captures may be used together >> (which >> indicates which ones can't be used together) and the CSE >> that groups >> capture resources. This seems to be an important aspect of >> CLUE but >> there doesn't appear to be a requirement driving it. >> >> [MB] As I mentioned previously, we don't need to have a >> requirement to >> justify every aspect of the solution. We don't want to get >> into having >> to define capture scene entries, etc. in the requirements. We >> don't >> need to backwards engineer the requirements to match the >> solution. [/MB] >> >> >> Regards, Christian >> >> >> On 16/09/2013 5:32 AM, Paul Kyzivat wrote: >> >> We started WGLC on the requirements two weeks ago. >> It has run for two weeks, and there have been *NO* >> comments!!! :-( >> >> I can't advance this document without better indication >> of >> support from the WG. So I'm extending this WGLC. I'll >> be away >> next weekend, so I will let this extension run another >> two >> weeks, ending Sunday Sept 29. >> >> We NEED NEED NEED your comments on this. Please review >> it again, >> and respond either positively or negatively, whether >> you think >> it is ready to progress. >> >> Thanks, >> Paul >> >> On 9/2/13 3:50 PM, Paul Kyzivat wrote: >> >> With this message I'm announcing the start of WGLC >> for >> draft-ietf-clue-telepresence-_**___requirements-05 >> >> >> >> This WGLC will last for roughly two weeks, ending at >> midnight GMT on >> Sunday September 15. >> >> It is important to have decisive results from a WGLC. >> (Silence doesn't do it.) >> So please, take a last careful look at these >> requirements >> and comment. >> If you like these as they are, please say so. >> >> Thanks, >> Paul (as co-chair) >> >> On 8/30/13 6:39 PM, internet-drafts@ietf.org >> > >> > >> >> >> wrote: >> >> >> A New Internet-Draft is available from the >> on-line >> Internet-Drafts >> directories. >> This draft is a work item of the ControLling >> mUltiple >> streams for >> tElepresence Working Group of the IETF. >> >> Title : Requirements for >> Telepresence >> Multi-Streams >> Author(s) : Allyn Romanow >> Stephen Botzko >> Mary Barnes >> Filename : >> >> draft-ietf-clue-telepresence-_**___requirements-05.txt >> >> >> Pages : 13 >> Date : 2013-08-30 >> >> Abstract: >> This memo discusses the requirements for a >> specification that enables >> telepresence interoperability, by >> describing the >> relationship between >> multiple RTP streams. In addition, the >> problem >> statement and >> definitions are also covered herein. >> >> >> The IETF datatracker status page for this draft >> is: >> https://datatracker.ietf.org/_**___doc/draft-ietf-clue-____** >> telepresence-requirements >> > telepresence-requirements >> > >> >> >> >> > telepresence-requirements >> > telepresence-requirements >> >> >> >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/___**_draft-ietf-clue-telepresence-** >> ____requirements-05 >> > _requirements-05 >> > >> >> >> >> > _requirements-05 >> > requirements-05 >> >> >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?__**__url2=draft-ietf-clue-____** >> telepresence-requirements-05 >> > telepresence-requirements-05 >> > >> >> >> >> > telepresence-requirements-05 >> > telepresence-requirements-05 >> >> >> >> >> >> >> Please note that it may take a couple of >> minutes from >> the time of >> submission >> until the htmlized version and diff are >> available at >> tools.ietf.org . >> >> >> >> Internet-Drafts are also available by anonymous >> FTP at: >> ftp://ftp.ietf.org/internet-__**__drafts/ >> >> > >> >> >> >> >> >> ______________________________** >> _____________________ >> clue mailing list >> clue@ietf.org > > >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> >> >> >> >> >> >> ______________________________** >> _____________________ >> clue mailing list >> clue@ietf.org > > >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> >> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org > > >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> >> >> >> >> >> >> ______________________________**_____________________ >> clue mailing list >> clue@ietf.org > > >> https://www.ietf.org/mailman/_**___listinfo/clue >> >> > >> >> >> >> >> >> >> >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> ______________________________**___________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/_**_listinfo/clue >> >> > >> >> >> > --047d7bdc0b6e74510904e69c9315 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 17, 2013 at 5:25 PM= , Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Mary,


On 9/17/13 5:04 PM, Mary Barnes wrote:
Yes. =A0There are other requirements using the term site. =A0If you look at=
the definition of "endpoint", there is the following statement: Endpoints can be anything from
multiscreen/multicamera rooms to handheld devices.

So, I think we are using site to refer explicitly/only to
multiscreen/multicamera rooms.

Are we? I think even then we are really talking about endpoints, but with o= ur design center biased towards multiscreen/multicamera rooms.=A0

E.g., when we are doing "site switching", a CLUE compatible cell = phone is still going to be treated as a site, together with the telepresenc= e "rooms" in the session.
[MB] Actually, we = don't define "site" in the CLUE framework either (and the wor= d appears 89 times in the use cases). =A0 So, maybe we *should* define site= and leave most of the requirements alone. =A0I think the word conveys the = concept well and I think we lose something if we change to endpoint in many= cases, which we should do consistently if we propose to do so in the requi= rements document. =A0 =A0[/MB]=A0

I'm not aware of *anything* that is specific to multiscreen/multicamera= endpoints.=A0


Maybe the easiest thing to do is to just
add a parenthetical comment in that sentence like the following:

=A0 =A0 =A0 =A0Endpoints can be anything from
=A0 =A0 =A0 =A0multiscreen/multicamera rooms (referred to as "sites&qu= ot;) to handheld devices.

Wouldn't that confuse the definition of site switching?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


Then, I do think it is appropriate to change the word "site" in R= EQMT-12
to "endpoint" as the intent of the requirement should also to end= points
other than multiscreen/multicamera rooms. =A0I think the use of "site&= quot; in
the other requirements is okay.

Mary.


On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu
<mailto:pkyzi= vat@alum.mit.edu>> wrote:

=A0 =A0 Mary,

=A0 =A0 IIUC, you are proposing to make a change from "site" to &= quot;endpoint"
=A0 =A0 in Reqmnt-12, and otherwise leave things alone?

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


=A0 =A0 On 9/17/13 2:06 PM, Mary Barnes wrote:

=A0 =A0 =A0 =A0 Hi Christian,

=A0 =A0 =A0 =A0 Thanks for taking the time to review this. Comments/respons= es
=A0 =A0 =A0 =A0 below [MB].

=A0 =A0 =A0 =A0 Mary.


=A0 =A0 =A0 =A0 On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves
=A0 =A0 =A0 =A0 <Christian.Groves@nteczone.com
=A0 =A0 =A0 =A0 <mailto:Christian.Groves@nteczone.com>
=A0 =A0 =A0 =A0 <mailto:Christian.Groves@__nteczone.com

=A0 =A0 =A0 =A0 <mailto:Christian.Groves@nteczone.com>>>

=A0 =A0 =A0 =A0 wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0Hello,

=A0 =A0 =A0 =A0 =A0 =A0 =A0Here are my comments to the WGLC:

=A0 =A0 =A0 =A0 =A0 =A0 =A01) Reqmt-1D - With regards to reqmt-1d: The solu= tion MUST
=A0 =A0 =A0 =A0 support a
=A0 =A0 =A0 =A0 =A0 =A0 =A0means to identify
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0the extent of individual video
=A0 =A0 =A0 =A0 captures in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0three dimensions.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Did we decide whether this was with respect to a= "plane of
=A0 =A0 =A0 =A0 interest"
=A0 =A0 =A0 =A0 =A0 =A0 =A0in 3 dimensions? and/or a volume (i.e. incorpora= ting a
=A0 =A0 =A0 =A0 depth aspect)
=A0 =A0 =A0 =A0 =A0 =A0 =A0in 3 dimensions? It probably would be good to cl= arify this
=A0 =A0 =A0 =A0 in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0requirements.

=A0 =A0 =A0 =A0 [MB] I don't know that this particular detail matters i= n the
=A0 =A0 =A0 =A0 requirements document. =A0[/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A02) General: At different places there are refere= nces to
=A0 =A0 =A0 =A0 particular
=A0 =A0 =A0 =A0 =A0 =A0 =A0use cases. However this doesn't appear to us= ed
=A0 =A0 =A0 =A0 consistently. e.g.
=A0 =A0 =A0 =A0 =A0 =A0 =A0Regmt-9 regarding interoperability between endpo= ints using
=A0 =A0 =A0 =A0 different
=A0 =A0 =A0 =A0 =A0 =A0 =A0numbers of streams makes references to the heter= ogeneous
=A0 =A0 =A0 =A0 use case.
=A0 =A0 =A0 =A0 =A0 =A0 =A0The heterogeneous use cases mentions different b= it rates etc,
=A0 =A0 =A0 =A0 =A0 =A0 =A0however Reqmts-8, 7 etc don't mention the us= e case? It
=A0 =A0 =A0 =A0 seems to me
=A0 =A0 =A0 =A0 =A0 =A0 =A0that if we include references to use cases that = we should
=A0 =A0 =A0 =A0 be consistent.

=A0 =A0 =A0 =A0 [MB] Not all requirements can be mapped directly to use cas= es -
=A0 =A0 =A0 =A0 e.g.,
=A0 =A0 =A0 =A0 16, 17 & 18. In the cases, where they can, we probably = should. The
=A0 =A0 =A0 =A0 references are intended to informative. [/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A03) REQMT-12: Rather than say "..more than t= wo <sites>"
=A0 =A0 =A0 =A0 should we use
=A0 =A0 =A0 =A0 =A0 =A0 =A0"..more than two endpoints". We don= 9;t have a definition for
=A0 =A0 =A0 =A0 "site".

=A0 =A0 =A0 =A0 [MB] We don't have an explicit definition but it can ce= rtainly be
=A0 =A0 =A0 =A0 derived from the context. We use "site" in severa= l other places
=A0 =A0 =A0 =A0 and just
=A0 =A0 =A0 =A0 replacing that with endpoint in those cases won't work = - e.g,. in
=A0 =A0 =A0 =A0 Section 4: =A0"If Alice and Bob are at different sites= , Alice needs to
=A0 =A0 =A0 =A0 tell Bob about the camera and sound equipment arrangement a= t her
=A0 =A0 =A0 =A0 site so
=A0 =A0 =A0 =A0 that Bob's receiver can create an accurate rendering of= her site."
=A0 =A0 =A0 =A0 That all said, I think we can replace the use of "site= " in that
=A0 =A0 =A0 =A0 requirement as that's consistent with all the other req= uirements.
=A0 =A0 =A0 =A0 [/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A04) General: Do we need to have some text in the = document that
=A0 =A0 =A0 =A0 =A0 =A0 =A0indicates that there may be other unspecified re= quirements
=A0 =A0 =A0 =A0 that may
=A0 =A0 =A0 =A0 =A0 =A0 =A0be implemented? The framework has a number of at= tributes
=A0 =A0 =A0 =A0 that aren't
=A0 =A0 =A0 =A0 =A0 =A0 =A0mentioned as part of the requirements e.g. scene=
=A0 =A0 =A0 =A0 description. Or
=A0 =A0 =A0 =A0 =A0 =A0 =A0alternatively do we capture this by adding a gen= eric
=A0 =A0 =A0 =A0 requirement
=A0 =A0 =A0 =A0 =A0 =A0 =A0regarding description of the content of captures= /scenes? The
=A0 =A0 =A0 =A0 =A0 =A0 =A0requirements are very focussed on spatial/render= aspects
=A0 =A0 =A0 =A0 rather than
=A0 =A0 =A0 =A0 =A0 =A0 =A0information pertaining to the selection of captu= res.

=A0 =A0 =A0 =A0 [MB] I do not believe so. =A0These are the bare bones requi= rements
=A0 =A0 =A0 =A0 - if we
=A0 =A0 =A0 =A0 don't have functionality to support these then we haven= 't done
=A0 =A0 =A0 =A0 our job.
=A0 =A0 =A0 =A0 =A0 =A0However, the solution can certainly define additiona= l
=A0 =A0 =A0 =A0 functionality,
=A0 =A0 =A0 =A0 that doesn't necessarily map to a specific requirement.= =A0The
=A0 =A0 =A0 =A0 requirements should not be specifying all the details of th= e
=A0 =A0 =A0 =A0 attributes
=A0 =A0 =A0 =A0 necessary to support the use cases - that's the objecti= ve of the
=A0 =A0 =A0 =A0 framework. Now, if you think there is a general requirement= that's
=A0 =A0 =A0 =A0 missing, certainly you can propose such. Realistically, req= uirements
=A0 =A0 =A0 =A0 documents are starting points to seed the solution work. On= ce the
=A0 =A0 =A0 =A0 solution is started unless the WG thinks a requirement can&= #39;t be met,
=A0 =A0 =A0 =A0 it's not necessarily productive to try to make the requ= irements
=A0 =A0 =A0 =A0 document
=A0 =A0 =A0 =A0 absolutely complete. =A0Indeed, a number of WGs actually ne= ver publish
=A0 =A0 =A0 =A0 requirements documents, but rather just cache them in an =A0 =A0 =A0 =A0 appendix for
=A0 =A0 =A0 =A0 historical purposes. [/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A05) General: There seems to be a requirement in C= LUE of the
=A0 =A0 =A0 =A0 ability
=A0 =A0 =A0 =A0 =A0 =A0 =A0to indicate how captures are related to resource= s. e.g. the STS
=A0 =A0 =A0 =A0 =A0 =A0 =A0mechanism indicates which captures may be used t= ogether (which
=A0 =A0 =A0 =A0 =A0 =A0 =A0indicates which ones can't be used together)= and the CSE
=A0 =A0 =A0 =A0 that groups
=A0 =A0 =A0 =A0 =A0 =A0 =A0capture resources. This seems to be an important= aspect of
=A0 =A0 =A0 =A0 CLUE but
=A0 =A0 =A0 =A0 =A0 =A0 =A0there doesn't appear to be a requirement dri= ving it.

=A0 =A0 =A0 =A0 [MB] As I mentioned previously, we don't need to have a=
=A0 =A0 =A0 =A0 requirement to
=A0 =A0 =A0 =A0 justify every aspect of the solution. =A0 We don't want= to get
=A0 =A0 =A0 =A0 into having
=A0 =A0 =A0 =A0 to define capture scene entries, etc. in the requirements. = =A0 We
=A0 =A0 =A0 =A0 don't
=A0 =A0 =A0 =A0 need to backwards engineer the requirements to match the =A0 =A0 =A0 =A0 solution. =A0[/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A0Regards, Christian


=A0 =A0 =A0 =A0 =A0 =A0 =A0On 16/09/2013 5:32 AM, Paul Kyzivat wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We started WGLC on the requirements two = weeks ago.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It has run for two weeks, and there have= been *NO*
=A0 =A0 =A0 =A0 comments!!! :-(

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I can't advance this document withou= t better indication of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support from the WG. So I'm extendin= g this WGLC. I'll
=A0 =A0 =A0 =A0 be away
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0next weekend, so I will let this extensi= on run another two
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0weeks, ending Sunday Sept 29.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We NEED NEED NEED your comments on this.= Please review
=A0 =A0 =A0 =A0 it again,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and respond either positively or negativ= ely, whether
=A0 =A0 =A0 =A0 you think
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it is ready to progress.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 9/2/13 3:50 PM, Paul Kyzivat wrote:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0With this message I'm announ= cing the start of WGLC for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-ietf-clue-telepresence-____requirements-05



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This WGLC will last for roughly = two weeks, ending at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0midnight GMT on
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sunday September 15.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It is important to have decisive= results from a WGLC.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Silence doesn't do it.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So please, take a last careful l= ook at these
=A0 =A0 =A0 =A0 requirements
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0and comment.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If you like these as they are, p= lease say so.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul (as co-chair)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 8/30/13 6:39 PM, internet-drafts@ietf.org<= /a>
=A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:internet-drafts@ietf.__org=

=A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A New Internet-Draft is = available from the on-line
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Internet-Drafts
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0directories.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This draft is a wor= k item of the ControLling
=A0 =A0 =A0 =A0 mUltiple
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0streams for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tElepresence Working Gro= up of the IETF.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Title =A0 =A0 = =A0 =A0 =A0 : Requirements for
=A0 =A0 =A0 =A0 Telepresence
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Multi-Streams
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Author(s) =A0 = =A0 =A0 : Allyn Romanow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stephen Botzko
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename =A0 = =A0 =A0 =A0:

=A0 =A0 =A0 =A0 draft-ietf-clue-telepresence-____requirements-05.txt=


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Pages =A0 =A0 = =A0 =A0 =A0 : 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Date =A0 =A0 = =A0 =A0 =A0 =A0: 2013-08-30

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 This memo discu= sses the requirements for a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0specification that enabl= es
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 telepresence in= teroperability, by
=A0 =A0 =A0 =A0 describing the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0relationship between
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiple RTP st= reams. =A0In addition, the
=A0 =A0 =A0 =A0 problem
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0statement and
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 definitions are= also covered herein.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The IETF datatracker sta= tus page for this draft is:
=A0 =A0 =A0 =A0 https://datatracker.i= etf.org/____doc/draft-ietf-clue-____telepresence-requirements=
=A0 =A0 =A0 =A0 <https://datatracker.i= etf.org/__doc/draft-ietf-clue-__telepresence-requirements= >



=A0 =A0 =A0 =A0 <https://datatracker.i= etf.org/__doc/draft-ietf-clue-__telepresence-requirements=
=A0 =A0 =A0 =A0 <https://datatracker.ietf.= org/doc/draft-ietf-clue-telepresence-requirements>>=



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0There's also a htmli= zed version available at:
=A0 =A0 =A0 =A0 http://tools.ietf.org/ht= ml/____draft-ietf-clue-telepresence-____requirements-05 =A0 =A0 =A0 =A0 <http://tools.ietf.org/ht= ml/__draft-ietf-clue-telepresence-__requirements-05>


=A0 =A0 =A0 =A0 <http://tools.ietf.org/ht= ml/__draft-ietf-clue-telepresence-__requirements-05
=A0 =A0 =A0 =A0 <http://tools.ietf.org/html/<= u>draft-ietf-clue-telepresence-requirements-05>>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A diff from the previous= version is available at:
=A0 =A0 =A0 =A0 http://www.ietf.= org/rfcdiff?____url2=3Ddraft-ietf-clue-____telepresence-requi= rements-05
=A0 =A0 =A0 =A0 <http://www.ietf.= org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requireme= nts-05>



=A0 =A0 =A0 =A0 <http://www.ietf.= org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requireme= nts-05
=A0 =A0 =A0 =A0 <http://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirements-05>>




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Please note that it may = take a couple of
=A0 =A0 =A0 =A0 minutes from
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the time of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0submission
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0until the htmlized versi= on and diff are
=A0 =A0 =A0 =A0 available at
=A0 =A0 =A0 =A0 tools.i= etf.org <http://= tools.ietf.org> <http://tools.ietf.org>.



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Internet-Drafts are also= available by anonymous
=A0 =A0 =A0 =A0 FTP at:
=A0 =A0 =A0 =A0 ftp://ftp.ietf.org/internet-____drafts/
=A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/internet= -__drafts/
=A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-drafts/>>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________= ___________________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org= /mailman/__listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>= >


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman= /__listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>= >


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________= __________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue= >
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/= __listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>= >


=A0 =A0 =A0 =A0 =A0 =A0 =A0_________________________________________= __________
=A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/____listinfo/clue=
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue= >

=A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__listin= fo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>= >




=A0 =A0 =A0 =A0 _________________________________________________ =A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>=


=A0 =A0 _________________________________________________
=A0 =A0 clue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>




--047d7bdc0b6e74510904e69c9315-- From Christian.Groves@nteczone.com Tue Sep 17 17:15:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7711E8159 for ; Tue, 17 Sep 2013 17:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtLmuu6ShVRD for ; Tue, 17 Sep 2013 17:15:54 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id D526011E8153 for ; Tue, 17 Sep 2013 17:15:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBANjvOFJ20Zly/2dsb2JhbAANQwqDP0zBN4ExgxkBAQEDAQEBATUbGwQGARALGAkWCAcJAwIBAgEVHxEGDQEFAgEBBRKHYg0Fpy+TCo4eBoFDB4QeA5NehUyTe4Ff Received: from ppp118-209-153-114.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.153.114]) by ipmail06.adl6.internode.on.net with ESMTP; 18 Sep 2013 09:45:51 +0930 Message-ID: <5238F0B3.3020902@nteczone.com> Date: Wed, 18 Sep 2013 10:15:47 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Mary Barnes References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 00:15:55 -0000 Hello Mary, Please see my replies below. Regards, Christian On 18/09/2013 4:06 AM, Mary Barnes wrote: > Hi Christian, > > Thanks for taking the time to review this. Comments/responses below [MB]. > > Mary. > > > On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > > > wrote: > > Hello, > > Here are my comments to the WGLC: > > 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support > a means to identify > the extent of individual video captures in > three dimensions. > > Did we decide whether this was with respect to a "plane of > interest" in 3 dimensions? and/or a volume (i.e. incorporating a > depth aspect) in 3 dimensions? It probably would be good to > clarify this in the requirements. > > [MB] I don't know that this particular detail matters in the > requirements document. [/MB] [CNG] I think that a requirement should be clear. Someone reads the framework and checks it against the requirement, did we meet the requirement or not? The way the requirement is written we can't say. > > 2) General: At different places there are references to particular > use cases. However this doesn't appear to used consistently. e.g. > Regmt-9 regarding interoperability between endpoints using > different numbers of streams makes references to the heterogeneous > use case. The heterogeneous use cases mentions different bit rates > etc, however Reqmts-8, 7 etc don't mention the use case? It seems > to me that if we include references to use cases that we should be > consistent. > > [MB] Not all requirements can be mapped directly to use cases - e.g., > 16, 17 & 18. In the cases, where they can, we probably should. The > references are intended to informative. [/MB] [CNG] I agree, if we can we probably should. I think consistency is the key. I think it would be good to add a sentence to the draft with respect to your comment that the references are intended to be informative. > > 3) REQMT-12: Rather than say "..more than two " should we > use "..more than two endpoints". We don't have a definition for > "site". > > [MB] We don't have an explicit definition but it can certainly be > derived from the context. We use "site" in several other places and > just replacing that with endpoint in those cases won't work - e.g,. in > Section 4: "If Alice and Bob are at different sites, Alice needs to > tell Bob about the camera and sound equipment arrangement at her site > so that Bob's receiver can create an accurate rendering of her site." > That all said, I think we can replace the use of "site" in that > requirement as that's consistent with all the other requirements. > [/MB] [CNG] My comment re: site was only on the requirement. > > > 4) General: Do we need to have some text in the document that > indicates that there may be other unspecified requirements that > may be implemented? The framework has a number of attributes that > aren't mentioned as part of the requirements e.g. scene > description. Or alternatively do we capture this by adding a > generic requirement regarding description of the content of > captures/scenes? The requirements are very focussed on > spatial/render aspects rather than information pertaining to the > selection of captures. > > [MB] I do not believe so. These are the bare bones requirements - if > we don't have functionality to support these then we haven't done our > job. However, the solution can certainly define additional > functionality, that doesn't necessarily map to a specific requirement. > The requirements should not be specifying all the details of the > attributes necessary to support the use cases - that's the objective > of the framework. Now, if you think there is a general requirement > that's missing, certainly you can propose such. Realistically, > requirements documents are starting points to seed the solution work. > Once the solution is started unless the WG thinks a requirement can't > be met, it's not necessarily productive to try to make the > requirements document absolutely complete. Indeed, a number of WGs > actually never publish requirements documents, but rather just cache > them in an appendix for historical purposes. [/MB] [CNG] I've got no problem with your explanation. If that's how the group sees the requirements then that's OK however I think we should document in the draft what the objective is and how its meant to be interpreted. We have to remember that someone may read the draft(RFC) in the future who doesn't have the benefit of a couple years involvement on the CLUE WG email lists. It should be clear to them why there is a difference between the requirements and the other documents. > > 5) General: There seems to be a requirement in CLUE of the ability > to indicate how captures are related to resources. e.g. the STS > mechanism indicates which captures may be used together (which > indicates which ones can't be used together) and the CSE that > groups capture resources. This seems to be an important aspect of > CLUE but there doesn't appear to be a requirement driving it. > > [MB] As I mentioned previously, we don't need to have a requirement to > justify every aspect of the solution. We don't want to get into > having to define capture scene entries, etc. in the requirements. We > don't need to backwards engineer the requirements to match the > solution. [/MB] [CNG] See my above comment. > > Regards, Christian > > > On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* comments!!! :-( > > I can't advance this document without better indication of > support from the WG. So I'm extending this WGLC. I'll be away > next weekend, so I will let this extension run another two > weeks, ending Sunday Sept 29. > > We NEED NEED NEED your comments on this. Please review it > again, and respond either positively or negatively, whether > you think it is ready to progress. > > Thanks, > Paul > > On 9/2/13 3:50 PM, Paul Kyzivat wrote: > > With this message I'm announcing the start of WGLC for > draft-ietf-clue-telepresence-requirements-05 > > This WGLC will last for roughly two weeks, ending at > midnight GMT on > Sunday September 15. > > It is important to have decisive results from a WGLC. > (Silence doesn't do it.) > So please, take a last careful look at these requirements > and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) > > On 8/30/13 6:39 PM, internet-drafts@ietf.org > wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts > directories. > This draft is a work item of the ControLling > mUltiple streams for > tElepresence Working Group of the IETF. > > Title : Requirements for Telepresence > Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : > draft-ietf-clue-telepresence-requirements-05.txt > Pages : 13 > Date : 2013-08-30 > > Abstract: > This memo discusses the requirements for a > specification that enables > telepresence interoperability, by describing the > relationship between > multiple RTP streams. In addition, the problem > statement and > definitions are also covered herein. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements > > > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-05 > > > > > Please note that it may take a couple of minutes from > the time of > submission > until the htmlized version and diff are available at > tools.ietf.org . > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From Christian.Groves@nteczone.com Tue Sep 17 20:15:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AC511E8195 for ; Tue, 17 Sep 2013 20:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkc6zBA0JHcx for ; Tue, 17 Sep 2013 20:15:40 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1BA11E819A for ; Tue, 17 Sep 2013 20:15:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAEsaOVJ20Zly/2dsb2JhbAANTcZ3g1IBBRslPRYYAwIBAgFLAQwIAQGvLJMFlAwDrSU Received: from ppp118-209-153-114.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.153.114]) by ipmail06.adl6.internode.on.net with ESMTP; 18 Sep 2013 12:45:35 +0930 Message-ID: <52391AD2.5000701@nteczone.com> Date: Wed, 18 Sep 2013 13:15:30 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 03:15:41 -0000 Hello Mark, At yesterday's interim you asked if I could use the MCC concept (draft-groves-clue-multi-content-00) to support the example in your draft ( draft-duckworth-clue-switching-example-01). I assume that you were talking about the scenario in section 2. I think it is worthwhile to consider the “Endpoint” advertisements also. >From a CLUE perspective how an endpoint chooses to render the received encodings is largely irrelevant as it is up to the local policy. I would assume the source Advertisements would be something like: Endpoint A - 4 screens, 3 cameras Endpoint B - 3 screens, 3 cameras Endpoint C - 3 screens, 3 cameras Endpoint D - 3 screens, 3 cameras Endpoints A-D: CaptureScene1[Description=Endpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] Endpoints E-G: CaptureScene1[Description=Endpoint y,VC1,CSE(VC1)] Note: The endpoints would be likely to use the same IDs in their respective Advertisements. Rather than considering what is displayed the MCC concepts concentrates more on what the MCU/Mixer sends. The mixer doesn’t know anything about the number of screens an endpoint has. My assumption from the figures is that if the 3 main screens are “site” switching that there is one capture encoding/media stream for each. The MCU switches in the applicable media into the stream based on voice activity [policy1]. I assume endpoint A will not see a capture from itself. The descriptions are just for information. Using the MCC concept the MCU would Advertise to endpoint A: ----------------------------------------------------------- CapScene2[Description=Endpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] CapScene3[Description=Endpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] CapScene4[Description=Endpoint D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] CapScene5[Description=Endpoint E,VC13,(CSE5(VC13)] CapScene6[Description=Endpoint F,VC14,(CSE6(VC13)] CapScene7[Description=Endpoint G,VC15,(CSE7(VC13)] // The above part effectively is the same as the input advertisements. There are no capture encodings associated with them. CapScene8[Description=Output3streammix, MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} {Encodinggroup1} MCC2(VC5,VC8,VC11,VC13,VC14,VC15) {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} {Encodinggroup2} MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} {Encodinggroup3} CSE8(MCC1,MCC2,MCC3) // The above part describes the switched 3 main streams that relate to site switching. MaxCaptures:1 indicates that only one capture from the MCC is sent at a particular time. The default if it wasn't included is 1 so it doesn't need to be sent but included for clarity. Sync-id:1 indicates that the source sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15 nothing will be sent in the other MCCs. CapScene9[Description=Output9streams, MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] // The above part indicates that there are 9 capture encodings. Each of the capture encodings may contain any captures from any source site with a maximum of one capture at a time. Which capture is present is determined by Policy2. If the MCU wanted to provide a composed capture encoding of the 9 captures it could Advertise in addition: CapScene10[Description=NineTiles, MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} CSE(MCC13) // As maxcaptures is 9 it indicates that the capture encoding contains information from up to 9 sources at a time. [CNG] The above arrangement allows a Consumer to understand how the captures relate to the source sites. It means a Consumer can choose not to receive information from a particular source. This is not possible according to the “one big scene” approach below. The Advertisement for Endpoint B in your draft would be identical to the above other than the captures from Endpoint A would be added and the captures from Endpoint B would be removed. I hope this provides some clarification. Regards, Christian From spromano@unina.it Wed Sep 18 01:08:13 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C5311E81C5 for ; Wed, 18 Sep 2013 01:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7+QJksTK9UZ for ; Wed, 18 Sep 2013 01:08:09 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 99C6011E8144 for ; Wed, 18 Sep 2013 01:08:08 -0700 (PDT) Received: from [143.225.162.130] ([143.225.162.130]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r8I8837Y023499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Sep 2013 10:08:03 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D38B2DAE-1039-46CE-9668-0BC828D3897E" From: Simon Pietro Romano In-Reply-To: <5238C2D7.4020200@alum.mit.edu> Date: Wed, 18 Sep 2013 10:08:30 +0200 Message-Id: <3FA6983D-8518-40BF-BA85-8D07583799AB@unina.it> References: <5238C2D7.4020200@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: CLUE Subject: Re: [clue] Proposal for dividing and restructuring Signaling work. X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 08:08:13 -0000 --Apple-Mail=_D38B2DAE-1039-46CE-9668-0BC828D3897E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello everybody, I like very much the diagram proposed in the slides and think the = separation of concerns is a good approach to let things evolve smoothly. = We'll work with this new philosophy in mind. Cheers, Simon Il giorno 17/set/2013, alle ore 23:00, Paul Kyzivat ha scritto: > Mary, >=20 > I do agree the clue protocol can be a separate document, as long as = the cut is done cleanly. I think that means it includes all the = messages, defined as XML elements that are exchanged over a single = reliable bidirectional medium, along with their semantics and = sequencing. The signaling document will then define how they are = transported. There will need to be a defined interface: the errors that = might occur when sending or receiving messages that the protocol needs = to cope with, and maybe some action(s) to reset/retry the transport. >=20 > That would, in principle, allow the protocol to be rehosted over some = other transport, though we have no specific plans to do that. >=20 > More comments on the rest later. >=20 > Thanks, > Paul >=20 > On 9/17/13 1:08 PM, Mary Barnes wrote: >> HI all, >>=20 >> The diagram I presented is included in the proceedings in the chair >> charts (slide 7): Agenda & Status (Chairs) >> = >>=20 >> The motivation for this suggestion is that we already have another >> individual doc that is describing details of the CLUE protocol. I >> believe that keeping all the details of that in a separate document = will >> make the work more manageable. Otherwise, I fear we will have one of >> those 200 page monster documents, which is difficult to share amongst >> multiple authors and a nightmare to progress. Even with this split, = my >> guess is that both these documents would be anywhere from 75-100 = pages >> when completed once we get all the details in, including error = handling, >> IANA registrations, security, etc. >>=20 >> So, here is my suggestion for the Abstract/Intro and ToC for the >> signaling document: >> OLD Abstract: >> This document specifies how signaling is conducted in the course of = CLUE >> sessions. This includes how SIP/SDP signaling is applied to CLUE >> sessions as well as defining a CLUE-specific signaling protocol that >> complements SIP/SDP and supports negotiation of CLUE application = level data. >>=20 >> NEW Abstract: >> This document specifies the signaling model for CLUE sessions. It >> describes the orchestration of SIP/SDP O/A with the CLUE protocol to >> support the >> CLUE use cases. This document identifies the SDP >> and RTP building blocks required to establish a CLUE session. >>=20 >> New ToC: >>=20 >> 1. Introduction >>=20 >> 2. Terminology >>=20 >> 3. Overview >>=20 >> This document describes the orchestration of the SIP SDP O/A = signaling with the CLUE protocol [reference]. The details of the SDP = and RTP building blocks are also identified, with relevant references to = the documents that are required for the overall CLUE solution. The = document provides details on the mapping that is required between = constructs in the CLUE Data model [ref] and SDP. This document also = discusses how CLUE would operate in an environment where one or more of = the participants does not support CLUE. A few examples are provided. A = separate document provides additional detailed call flows of the = realization of the CLUE use cases based upon the protocol details = defined in this document. >>=20 >> --- A nice diagram would also help. [In my opinion, this is a better = place to introduce all the CLUE solution work, which I previously = suggested should be in the Framework.] >>=20 >> 4. CLUE use of SDP O/A >>=20 >> 4.1. Establishing the CLUE channel >> 4.2. Representing CLUE Encodings in SDP >> 4.3. Representing CLUE Encoding Groups in SDP >> 4.4. Signaling CLUE control of "m" lines >> 4.5. Ensuring interoperability with non-CLUE devices >>=20 >> 5. Interaction of CLUE and SDP negotiations >> 5.1 Independence of SDP and CLUE negotiation >> 5.2. Recommendations for operating with non-atomic operations >> 5.3. Constraints on sending media >>=20 >>=20 >> 6. Example: A call between two CLUE-capable endpoints >>=20 >> 7. Example: A call between a CLUE and non-CLUE-capable endpoint 38 >>=20 >> 8. CLUE requirements on SDP O/A >>=20 >> 9. SIP Signaling >>=20 >> 10. Interoperation with non-CLUE aware SIP Devices [I'd rather ditch = the term "legacy"] >>=20 >> 11. CLUE over RTCWEB >>=20 >> ....remainder is the same.... >>=20 >> Here's the suggestion for the Abstract/Intro and ToC for the CLUE = protocol document: >>=20 >> This document provides the details for the CLUE protocol based upon = the >> constructs defined in the CLUE framework. The CLUE protocol is used = in >> conjunction with SIP/SDP to establish CLUE sessions to support the = CLUE >> use cases. The CLUE protocol is based on an XML schema that provides >> versioning and extensibility. The CLUE protocol carries CLUE >> information, as identified in the framework, in the form of XML >> documents and fragments conforming to the CLUE data model schema. >>=20 >> Toc: >>=20 >> 1. Introduction >>=20 >> 2. Terminology >>=20 >> 3. Overview of the CLUE protocol messages >> 3.1. ADVERTISEMENT >> 3.2. CONFIGURE >> 3.3. RESPONSE >> 3.4. RE-ADV . >> 4. Protocol state machines >> 4.1 Media Consumer's state machine >> 4.2 Media Provider's state machine >>=20 >> 5. Message Sequencing >>=20 >> 6. Message Schema >>=20 >> 7. CLUE protocol XML schema extensibility and versioning >>=20 >> 7.1. Aspect 1 - new information within existing messages >> 7.2. Aspect 2 - new messages >>=20 >> 8. Examples >>=20 >> 9. Message Transport >>=20 >> 10. Message Framing >>=20 >> ...other stuff like Security considerations, IANA, etc. >>=20 >> If folks could share their thoughts and opinions on this so we can = get >> things moving forward, that would be great. Ideally, if we follow = this >> approach, finding a new editor for the WG signaling document won't = seem >> to be such an onerous task. >>=20 >> Regards, >> Mary. >=20 >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_D38B2DAE-1039-46CE-9668-0BC828D3897E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hello = everybody,

I like very much the diagram proposed in = the slides and think the separation of concerns is a good approach to = let things evolve smoothly. We'll work with this new philosophy  in = mind.

Cheers,

Simon

Il giorno 17/set/2013, alle ore 23:00, Paul Kyzivat = ha scritto:

Mary,

I do agree the clue protocol can be a = separate document, as long as the cut is done cleanly. I think that = means it includes all the messages, defined as XML elements that are = exchanged over a single reliable bidirectional medium, along with their = semantics and sequencing. The signaling document will then define how = they are transported. There will need to be a defined interface: the = errors that might occur when sending or receiving messages that the = protocol needs to cope with, and maybe some action(s) to reset/retry the = transport.

That would, in principle, allow the protocol to be = rehosted over some other transport, though we have no specific plans to = do that.

More comments on the rest later.

= Thanks,
Paul

On 9/17/13 1:08 PM, = Mary Barnes wrote:
HI = all,

The diagram I = presented is included in the proceedings in the = chair
charts (slide 7): Agenda = & Status (Chairs)
<http://www.ietf.org/proceedings/interim/20= 13/09/17/clue/slides/slides-interim-2013-clue-3-0.pptx>

The motivation for this suggestion is that we already have = another
individual doc that is = describing details of the CLUE protocol. =  I
believe that keeping = all the details of that in a separate document = will
make the work more = manageable. Otherwise, I fear we will have one = of
those 200 page monster = documents, which is difficult to share = amongst
multiple authors and a = nightmare to progress.   Even with this split, = my
guess is that both these = documents would be anywhere from 75-100 = pages
when completed once we = get all the details in, including error = handling,
IANA registrations, = security, etc.

So, here is my = suggestion for the Abstract/Intro and ToC for = the
signaling = document:
OLD = Abstract:
This document = specifies how signaling is conducted in the course of = CLUE
sessions. This includes = how SIP/SDP signaling is applied to CLUE
sessions as well as defining a CLUE-specific signaling = protocol that
complements = SIP/SDP and supports negotiation of CLUE application level = data.

NEW = Abstract:
This document = specifies the signaling model for CLUE sessions. = It
describes the orchestration = of SIP/SDP O/A with the CLUE protocol to
support the
CLUE = use cases. This document identifies the SDP
and RTP building blocks required to establish a CLUE = session.

New = ToC:

1. = Introduction

2. = Terminology

3. = Overview

This document = describes the orchestration of the SIP SDP O/A signaling with the CLUE = protocol [reference].   The details of the SDP and RTP = building blocks are also identified, with relevant references to the = documents that are required for the overall CLUE solution. The document = provides details on the mapping that is required between constructs in = the CLUE Data model [ref] and SDP.  This document also discusses = how CLUE would operate in an environment where one or more of the = participants does not support CLUE.  A few examples are provided. =  A separate document provides additional detailed call flows of the = realization of the CLUE use cases based upon the protocol details = defined in this document.

--- A nice = diagram would also help.  [In my opinion, this is a better place to = introduce all the CLUE solution work, which I previously suggested = should be in the Framework.]

4.  CLUE = use of SDP O/A

=     4.1.  Establishing the CLUE = channel
=     4.2.  Representing CLUE Encodings in = SDP
=     4.3.  Representing CLUE Encoding Groups in = SDP
=     4.4.  Signaling CLUE control of "m" = lines
=      4.5.  Ensuring interoperability with = non-CLUE devices

5. =  Interaction of CLUE and SDP = negotiations
=      5.1 Independence of SDP and CLUE = negotiation
=      5.2.  Recommendations for operating = with non-atomic operations
=      5.3.  Constraints on sending = media


6. =  Example: A call between two CLUE-capable = endpoints

7. =  Example: A call between a CLUE and non-CLUE-capable endpoint =   38

8.  CLUE = requirements on SDP O/A

9.  SIP = Signaling

10. = Interoperation with non-CLUE aware SIP Devices [I'd rather ditch the = term "legacy"]

11. CLUE over = RTCWEB

....remainder = is the same....

Here's the = suggestion for the Abstract/Intro and ToC for the CLUE protocol = document:

This document = provides the details for the CLUE protocol based upon = the
constructs defined in the = CLUE framework.  The CLUE protocol is used = in
conjunction with SIP/SDP to = establish CLUE sessions to support the CLUE
use cases.  The CLUE protocol is based on an XML = schema that provides
versioning = and extensibility. The CLUE protocol carries = CLUE
information, as = identified in the framework, in the form of = XML
documents and fragments = conforming to the CLUE data model schema.

Toc:

1. = Introduction

2. =  Terminology

3. =  Overview of the CLUE protocol messages
     3.1. =  ADVERTISEMENT
=      3.2. =  CONFIGURE
=      3.3. =  RESPONSE
=      3.4.  RE-ADV = .
4.  Protocol state = machines
=     4.1 Media Consumer's state = machine
=     4.2 Media Provider's state = machine

5. =  Message Sequencing

6. =  Message Schema

7.  CLUE = protocol XML schema extensibility and = versioning

=      7.1.  Aspect 1 - new information = within existing messages
=      7.2.  Aspect 2 - new = messages

8. =  Examples

9. =  Message Transport

10. =  Message Framing

...other stuff = like Security considerations, IANA, etc.

If folks could = share their thoughts and opinions on this so we can = get
things moving forward, = that would be great.  Ideally, if we follow = this
approach, finding a new = editor for the WG signaling document won't = seem
to be such an onerous = task.

Regards,
Mary.



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

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





= --Apple-Mail=_D38B2DAE-1039-46CE-9668-0BC828D3897E-- From ron.even.tlv@gmail.com Wed Sep 18 02:24:46 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFAA11E820D for ; Wed, 18 Sep 2013 02:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daw7TkNDDkLw for ; Wed, 18 Sep 2013 02:24:44 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B8A3F21F9C8E for ; Wed, 18 Sep 2013 02:23:49 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id r16so3334300ead.3 for ; Wed, 18 Sep 2013 02:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=7GhZnoOfFbwoQzWVZrPHuqgoqPCsbHnvRycSZjIf+zE=; b=B53cnp0l12XTZKagugHvlnXhZtjFwcrCT89YNPj1j4+VeqroWm2CXscW3DjmelDon2 S91y70r08HehVuiLeIwmFsJWb8ulTQFC7j4369poEu0lzb4VhH+eLSdIDNhzmuoRucFx qJJqzsZTT1ikj0FPernujUiySEgek0U3lNPexJ6PwnwtLIKHTa68zEqwjku0In6MwVZA eqEoXnqAodzwIxRcUk6m/aKhf2al23xqgES+B6hWtnfKUI0K1UX+gbeCwEuJm7TQ0ykc ODGdvfMIbbX1K+sG358xynpK7eWQWfb6IBJFt4qeiPU3ZDffcqAF0CTrq7kLkCWlg1wK JbRQ== X-Received: by 10.15.43.13 with SMTP id w13mr57995713eev.37.1379496228761; Wed, 18 Sep 2013 02:23:48 -0700 (PDT) Received: from RoniE (bzq-79-181-232-77.red.bezeqint.net. [79.181.232.77]) by mx.google.com with ESMTPSA id a43sm1233752eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 18 Sep 2013 02:23:48 -0700 (PDT) From: "Roni Even" To: Date: Wed, 18 Sep 2013 12:20:56 +0300 Message-ID: <028101ceb450$632bc7c0$29835740$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0282_01CEB469.8879C310" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac60UE+yTboK3PioR12Q8SLxoGEsmg== Content-Language: en-us Subject: [clue] CLUE SDP signaling and MMUSIC unfied plan - issues raised in the interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 09:24:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0282_01CEB469.8879C310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, At the CLUE interim meeting (September 17th) this issue was brought out as part of the RTP mapping presentation. MMSUSIC decided to use the "unified" plan for RTCweb. The plan propose that an m-line will describe a media source or media stream track. In CLUE terms this is a media capture. The data from a media source can be encoded as a single or multiple media streams (RTP media stream) or CLUE capture encodings. Examples for the multiple media streams may be a simulcast proposal of different resolutions streams or a FEC (forward error correction) stream to protect the media stream. The CLUE signaling draft (individual draft) propose that each SDP m-line represent a capture encoding and uses the SDP label attribute to map SDP information to CLUE. This does not work with "unified" plan since the label attribute is an SDP media level attribute. http://tools.ietf.org/id/draft-even-mmusic-application-token-01.txt discuss some of the issues with using an SDP m-line to describe a media source including support for FEC and simulcast. The simulcast support refers to http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02. Note that a FEC stream can protect multiple media capture (one FEC stream protect all three RTP streams from the three cameras) I also think that "bundle" is not an issue since it does not care what an m-line describes. Some questions to discuss 1. Does CLUE want to support unified or have an SDP m-line describe a media source or do we have an m-line describe a capture encoding or media stream (the relations between the m-line can be described SDP group attribute or in the CLUE protocol) 2. How do we describe the FEC stream. This is not a media stream and it is not really a capture encoding. So do we only have it in the SDP and no representation in CLUE. This will mean that it is not part of an encoding group so the total bandwidth limit will be based on SDP and not only on the encoding group. (this will relate also to the discussion about how do we describe the limits for encoding group (CLUE or SDP). Currently the authors of the RTP mapping draft (Jonathan and I) are going to update the document assuming that an m-line represent a capture encoding (not "unified") and that FEC is only described in SDP. Please look at the application token draft and provide feedback Thank Roni Even ------=_NextPart_000_0282_01CEB469.8879C310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the CLUE = interim meeting (September 17th) this issue was brought out = as part of the RTP mapping presentation.

MMSUSIC decided to use the “unified” plan = for RTCweb. The plan propose that an m-line will describe a media source = or media stream track. In CLUE terms this is a media = capture.

The data from a media source = can be encoded as a single or multiple media streams (RTP media stream) = or CLUE capture encodings. Examples for the multiple media streams may = be a simulcast proposal of different resolutions streams or a FEC = (forward error correction) stream to protect the media = stream.

 

The CLUE signaling draft (individual draft) propose = that each SDP m-line represent a capture encoding and uses the SDP label = attribute to map SDP information to CLUE.  This does not work with = “unified” plan since the label attribute is an SDP media = level attribute.

 

 

 

 

 

http://tools.ietf.org/id/draft-even-mmusic-application-token-01.txt discuss some of the issues with using an SDP m-line to describe a = media source including support for FEC and simulcast. The simulcast = support refers to http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02= .

 

Note that a FEC stream can protect multiple media = capture (one FEC stream protect all three RTP streams from the three = cameras)

 

I also think that “bundle” is not an issue = since it does not care what an m-line describes.

 

Some = questions to discuss

 

1.       = Does CLUE want to support = unified or have an SDP m-line describe a media source or do we have an = m-line describe a capture encoding or media stream (the relations = between the m-line can be described SDP group attribute or in the CLUE = protocol)

2.       = How do we describe the = FEC stream. This is not a media stream and it is not really a capture = encoding. So do we only have it in the SDP and no representation in = CLUE. This will mean that it is not part of an encoding group so the = total bandwidth limit will be based on SDP and not only on the encoding = group. (this will relate also to the discussion about how do we describe = the limits for encoding group (CLUE or SDP).

 

Currently = the authors of the RTP mapping draft (Jonathan and I) are going to = update the document assuming that an m-line represent a capture encoding = (not “unified”) and that FEC is only described in = SDP.

 

Please look at the application token draft and provide = feedback

 

Thank

Roni Even =

------=_NextPart_000_0282_01CEB469.8879C310-- From pkyzivat@alum.mit.edu Wed Sep 18 13:49:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7F211E8123 for ; Wed, 18 Sep 2013 13:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyAsAp7FoRj1 for ; Wed, 18 Sep 2013 13:49:22 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7C011E8121 for ; Wed, 18 Sep 2013 13:49:22 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id SbCQ1m0051wpRvQ54kpM0U; Wed, 18 Sep 2013 20:49:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id SkpM1m00c3ZTu2S3ekpMgl; Wed, 18 Sep 2013 20:49:21 +0000 Message-ID: <523A11D1.5050206@alum.mit.edu> Date: Wed, 18 Sep 2013 16:49:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130917095554.3962.44448.idtracker@ietfa.amsl.com> <52382850.2020709@unina.it> In-Reply-To: <52382850.2020709@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379537361; bh=4ILCr33cBDT3LTJGWSbpTp9cXqWfsNqCZY7kz4Bk9pI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Xx2cnsNN6C2jvFW/Peswkr75Km1NRQpVbm4QgNqtVi9f+BMtAT7ckb/AiU7FNpdzV G9PKYyKXOymptpUm4zWvB0W8dF/5ekuBYvGSIOtkedu/Csg6OPKPEkcHFmicvKHt8A mWOnGWUNJhO+My14LHqtEObeW+MSYM93+KSEcoV16Wi1x42phe5YsuTPcwMljwT/3V 17tEyvhIVXAxqbzlwGgHdBSFd3LQziuwoaxcOcoEh6G8a+3xrOXG3oqgD3g+BiWgRt CPhMbM/2aaGfJXsUsTgV3Fsv8tRHycnbvKDmQO2lMcf8s+i92cnu4mDJxVDwRgheng FmLSLBgf6ii2w== Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 20:49:27 -0000 Hi again Roberta & Simon, Now some comments on the state machines and messages: * Demuxing messages to provider/consumer state machines: We are assuming a single channel for both. So messages will need to be identified and dispatched to one or the other of the state machines. That will require parsing the message to determine its type. Won't parse errors occur there? This also requires that every message type be specific to one or the other of state machines. That is true so far for most of the messages you define, but not for RESPONSE? So how is RESPONSE dispatched? What about extension messages? What should happen to those? Errors from the channel while reading a message may affect neither state machine, or both. Recovering from fatal errors may require closing and reestablishing either the transport, or the channel within the transport. If we are to separate the protocol from the rest of the signaling, then I think we will want a transport abstraction over the sctp data channel, that the protocol deals with. (We can jointly negotiation what that should look like.) Then the protocol document will still need to deal with parsing messages, dispatching to the proper state machine, etc. The the signaling draft can deal with mapping that abstraction onto SCTP, and worry more about the error cases. But somewhere we must address what happens when the clue protocol becomes unavailable, either intentionally or because of unrecoverable error. * Media Consumer: Upon receiving a valid ADV, is the consumer obligated to send a CONF right away? It may be that the consumer needs to do some human interaction to decide what to include in the CONF message. In that case, must it send some CONF immediately and then another later after the human input? (The receive error RESP transition from this state only makes sense if the CONF isn't sent immediately, and so new messages can be noticed.) In ADV RECEIVED state, I think parsing must already have been done, so syntax errors must have already been handled. The remaining processing that could result in errors is semantic. Is there a reason for using RE-ADV rather than a RESPONSE message to indicate errors with the ADV? Suppose ADV1 is received, and CONF1 is sent. Then ADV2 is received. This moves to ADV RECEIVED state, and CONF2 is sent. Then RESPONSE1 is received (might be either OK or failure, assume OK) while in TRYING state. That moves to IN CALL. Then RESPONSE2 is received and again could be either OK or failure. No transitions are defined. (ISTM that in general only a response matched to the most recent CONF should be considered. Responses to other CONFs should be treated differently. Or else there may need to be a "transaction state machine" for each ADV and CONF.) In TERMINATED state, what effect should this have on the media provider state machine? If an error leads to the TERMINATED state (in either media producer or media consumer) what impact do you anticipate that may have on the other state machine? * Media Provider: In WAIT FOR CONF, do you imagine a short timeout, or a long one? Must it be long enough to allow for human interaction by the consumer? What if the consumer won't be ready to make a decision for a long time? In the TIMEOUT state, after how many timeouts (or equivalently, how much elapsed time without a CONF) do you envision would be reasonable before giving up? * Section 3.2 (CONFIGURE) | USAGE | The MC can send a CONF after the reception of | | | an ADV or each time it wants to request other | | | advertised captures to the MP. | "can send" implies this is optional. If so, it isn't good as an ack that the ADVERTISEMENT was processed and found acceptable. If you are assuming a "no news is good news", then it would be good to explicitly say so. (I'm dubious of that.) * Section 3.3 (RESPONSE) The usage for this says it is just for CONFIGURE, while RE-ADV is an error-only response for ADVERTISEMENT. But RESPONSE has a lot of generic error types that could apply to all messages, not just CONFIGURE. And what should be sent in response to a message of some other (or unknown) type? Thanks, Paul P.S. I will have very spotty network access from now until next Tuesday. On 9/17/13 6:00 AM, Roberta Presta wrote: > > > Hi all, > > we have added in this new version some considerations about protocol > versioning and extension introduced in the last team call. > Cheers, > > Roberta > > > -------- Messaggio originale -------- > Oggetto: New Version Notification for draft-presta-clue-protocol-01.txt > Data: Tue, 17 Sep 2013 02:55:54 -0700 > Mittente: internet-drafts@ietf.org > A: Roberta Presta , Simon Pietro Romano > , Simon Romano > > > > A new version of I-D, draft-presta-clue-protocol-01.txt > has been successfully submitted by Roberta Presta and posted to the > IETF repository. > > Filename: draft-presta-clue-protocol > Revision: 01 > Title: CLUE protocol > Creation date: 2013-09-17 > Group: Individual Submission > Number of pages: 17 > URL:http://www.ietf.org/internet-drafts/draft-presta-clue-protocol-01.txt > Status:http://datatracker.ietf.org/doc/draft-presta-clue-protocol > Htmlized:http://tools.ietf.org/html/draft-presta-clue-protocol-01 > Diff:http://www.ietf.org/rfcdiff?url2=draft-presta-clue-protocol-01 > > Abstract: > ToDo. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From michael.hammer@yaanatech.com Wed Sep 18 18:17:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F171511E80D5 for ; Wed, 18 Sep 2013 18:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOwnoQxreZl4 for ; Wed, 18 Sep 2013 18:16:57 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 0C21111E8162 for ; Wed, 18 Sep 2013 18:16:57 -0700 (PDT) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.01.0218.012; Wed, 18 Sep 2013 05:53:07 -0700 From: Michael Hammer To: "mary.ietf.barnes@gmail.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt Thread-Index: AQHOskpOGJQ41sUL0UG37BBMOb7RO5nJyJiAgADpbACAACe4AIAACeqAgAAWrQCAAA+fgIAAbTWg Date: Wed, 18 Sep 2013 12:53:05 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBEDAC0F@sc9-ex2k10mb1.corp.yaanatech.com> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <5238BB74.6090907@alum.mit.edu> <5238D6CA.3080500@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.136] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0011_01CEB44C.7D035E50" MIME-Version: 1.0 Cc: "clue@ietf.org" Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 01:17:04 -0000 ------=_NextPart_000_0011_01CEB44C.7D035E50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0012_01CEB44C.7D035E50" ------=_NextPart_001_0012_01CEB44C.7D035E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Or make reference to a "site controller". After all, I don't think it is the door or lights or seats that are responding to the signaling. Mike From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Tuesday, September 17, 2013 7:21 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat wrote: Mary, On 9/17/13 5:04 PM, Mary Barnes wrote: Yes. There are other requirements using the term site. If you look at the definition of "endpoint", there is the following statement: Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. So, I think we are using site to refer explicitly/only to multiscreen/multicamera rooms. Are we? I think even then we are really talking about endpoints, but with our design center biased towards multiscreen/multicamera rooms. E.g., when we are doing "site switching", a CLUE compatible cell phone is still going to be treated as a site, together with the telepresence "rooms" in the session. [MB] Actually, we don't define "site" in the CLUE framework either (and the word appears 89 times in the use cases). So, maybe we *should* define site and leave most of the requirements alone. I think the word conveys the concept well and I think we lose something if we change to endpoint in many cases, which we should do consistently if we propose to do so in the requirements document. [/MB] I'm not aware of *anything* that is specific to multiscreen/multicamera endpoints. Maybe the easiest thing to do is to just add a parenthetical comment in that sentence like the following: Endpoints can be anything from multiscreen/multicamera rooms (referred to as "sites") to handheld devices. Wouldn't that confuse the definition of site switching? Thanks, Paul Then, I do think it is appropriate to change the word "site" in REQMT-12 to "endpoint" as the intent of the requirement should also to endpoints other than multiscreen/multicamera rooms. I think the use of "site" in the other requirements is okay. Mary. On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat > wrote: Mary, IIUC, you are proposing to make a change from "site" to "endpoint" in Reqmnt-12, and otherwise leave things alone? Thanks, Paul On 9/17/13 2:06 PM, Mary Barnes wrote: Hi Christian, Thanks for taking the time to review this. Comments/responses below [MB]. Mary. On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves >> wrote: Hello, Here are my comments to the WGLC: 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a means to identify the extent of individual video captures in three dimensions. Did we decide whether this was with respect to a "plane of interest" in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect) in 3 dimensions? It probably would be good to clarify this in the requirements. [MB] I don't know that this particular detail matters in the requirements document. [/MB] 2) General: At different places there are references to particular use cases. However this doesn't appear to used consistently. e.g. Regmt-9 regarding interoperability between endpoints using different numbers of streams makes references to the heterogeneous use case. The heterogeneous use cases mentions different bit rates etc, however Reqmts-8, 7 etc don't mention the use case? It seems to me that if we include references to use cases that we should be consistent. [MB] Not all requirements can be mapped directly to use cases - e.g., 16, 17 & 18. In the cases, where they can, we probably should. The references are intended to informative. [/MB] 3) REQMT-12: Rather than say "..more than two " should we use "..more than two endpoints". We don't have a definition for "site". [MB] We don't have an explicit definition but it can certainly be derived from the context. We use "site" in several other places and just replacing that with endpoint in those cases won't work - e.g,. in Section 4: "If Alice and Bob are at different sites, Alice needs to tell Bob about the camera and sound equipment arrangement at her site so that Bob's receiver can create an accurate rendering of her site." That all said, I think we can replace the use of "site" in that requirement as that's consistent with all the other requirements. [/MB] 4) General: Do we need to have some text in the document that indicates that there may be other unspecified requirements that may be implemented? The framework has a number of attributes that aren't mentioned as part of the requirements e.g. scene description. Or alternatively do we capture this by adding a generic requirement regarding description of the content of captures/scenes? The requirements are very focussed on spatial/render aspects rather than information pertaining to the selection of captures. [MB] I do not believe so. These are the bare bones requirements - if we don't have functionality to support these then we haven't done our job. However, the solution can certainly define additional functionality, that doesn't necessarily map to a specific requirement. The requirements should not be specifying all the details of the attributes necessary to support the use cases - that's the objective of the framework. Now, if you think there is a general requirement that's missing, certainly you can propose such. Realistically, requirements documents are starting points to seed the solution work. Once the solution is started unless the WG thinks a requirement can't be met, it's not necessarily productive to try to make the requirements document absolutely complete. Indeed, a number of WGs actually never publish requirements documents, but rather just cache them in an appendix for historical purposes. [/MB] 5) General: There seems to be a requirement in CLUE of the ability to indicate how captures are related to resources. e.g. the STS mechanism indicates which captures may be used together (which indicates which ones can't be used together) and the CSE that groups capture resources. This seems to be an important aspect of CLUE but there doesn't appear to be a requirement driving it. [MB] As I mentioned previously, we don't need to have a requirement to justify every aspect of the solution. We don't want to get into having to define capture scene entries, etc. in the requirements. We don't need to backwards engineer the requirements to match the solution. [/MB] Regards, Christian On 16/09/2013 5:32 AM, Paul Kyzivat wrote: We started WGLC on the requirements two weeks ago. It has run for two weeks, and there have been *NO* comments!!! :-( I can't advance this document without better indication of support from the WG. So I'm extending this WGLC. I'll be away next weekend, so I will let this extension run another two weeks, ending Sunday Sept 29. We NEED NEED NEED your comments on this. Please review it again, and respond either positively or negatively, whether you think it is ready to progress. Thanks, Paul On 9/2/13 3:50 PM, Paul Kyzivat wrote: With this message I'm announcing the start of WGLC for draft-ietf-clue-telepresence-____requirements-05 This WGLC will last for roughly two weeks, ending at midnight GMT on Sunday September 15. It is important to have decisive results from a WGLC. (Silence doesn't do it.) So please, take a last careful look at these requirements and comment. If you like these as they are, please say so. Thanks, Paul (as co-chair) On 8/30/13 6:39 PM, internet-drafts@ietf.org > wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-____requirements-05.txt Pages : 13 Date : 2013-08-30 Abstract: This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requir ements > There's also a htmlized version available at: http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements -05 > A diff from the previous version is available at: http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requir ements-05 > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-____drafts/ > ___________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/____listinfo/clue > _________________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/__listinfo/clue _________________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/__listinfo/clue ------=_NextPart_001_0012_01CEB44C.7D035E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Or make reference to a “site = controller”.

 

After all, I don’t think it is the door or lights or seats that = are responding to the signaling.

 

Mike

 

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: Tuesday, September 17, 2013 7:21 = PM
To: Paul Kyzivat
Cc: CLUE
Subject: Re: = [clue] REMINDER!!! WGLC: = draft-ietf-clue-telepresence-requirements-05.txt

 

On = Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

Mary,



On 9/17/13 5:04 PM, Mary Barnes = wrote:

Yes.  There are other = requirements using the term site.  If you look at
the definition = of "endpoint", there is the following statement:
Endpoints = can be anything from
multiscreen/multicamera rooms to handheld = devices.

So, I think we are using site to refer explicitly/only = to
multiscreen/multicamera rooms.

 

Are = we? I think even then we are really talking about endpoints, but with = our design center biased towards multiscreen/multicamera = rooms. 


E.g., = when we are doing "site switching", a CLUE compatible cell = phone is still going to be treated as a site, together with the = telepresence "rooms" in the = session.

[MB] = Actually, we don't define "site" in the CLUE framework either = (and the word appears 89 times in the use cases).   So, maybe we = *should* define site and leave most of the requirements alone.  I = think the word conveys the concept well and I think we lose something if = we change to endpoint in many cases, which we should do consistently if = we propose to do so in the requirements document.   =  [/MB] 


I'm = not aware of *anything* that is specific to multiscreen/multicamera = endpoints. 

 

Maybe the easiest thing to do is to just
add a = parenthetical comment in that sentence like the following:

  =      Endpoints can be anything from
    =    multiscreen/multicamera rooms (referred to as = "sites") to handheld devices.

 

Wouldn't that confuse the definition of site = switching?

        Thanks,
    =     Paul

 

Then, I do think it is appropriate to change the word = "site" in REQMT-12
to "endpoint" as the intent of = the requirement should also to endpoints
other than = multiscreen/multicamera rooms.  I think the use of "site" = in
the other requirements is okay.

 

Mary.


On Tue, Sep 17, 2013 at 3:28 PM, Paul = Kyzivat <pkyzivat@alum.mit.edu

<mailto:pkyzivat@alum.mit.edu>> wrote:

  =   Mary,

    IIUC, you are proposing to make a = change from "site" to "endpoint"
    in = Reqmnt-12, and otherwise leave things alone?

      =        Thanks,
          =    Paul


    On 9/17/13 2:06 PM, Mary = Barnes wrote:

        Hi = Christian,

        Thanks for taking the time = to review this. Comments/responses
        below = [MB].

        Mary.


    =     On Mon, Sep 16, 2013 at 11:10 PM, Christian = Groves
        <Christian.Groves@nteczone.com
    =     <mailto:Christian.Groves@nteczone.com>

        <mailto:Christian.Groves@__nteczone.com


        <mailto:Christian.Groves@nteczone.com>>>

&n= bsp;       wrote:

        =      Hello,

          =    Here are my comments to the WGLC:

    =          1) Reqmt-1D - With regards to = reqmt-1d: The solution MUST
        support = a
             means to = identify
                =                     =    the extent of individual video
      =   captures in
              =                     =      three dimensions.

        =      Did we decide whether this was with respect to a = "plane of
        interest"
  =            in 3 dimensions? and/or a = volume (i.e. incorporating a
        depth = aspect)
             in 3 = dimensions? It probably would be good to clarify this
    =     in the
            =  requirements.

        [MB] I don't know = that this particular detail matters in the
      =   requirements document.  [/MB]


    =          2) General: At different places there = are references to
        particular
  =            use cases. However this doesn't = appear to used
        consistently. = e.g.
             Regmt-9 = regarding interoperability between endpoints using
    =     different
            =  numbers of streams makes references to the heterogeneous
  =       use case.
          =    The heterogeneous use cases mentions different bit rates = etc,
             however = Reqmts-8, 7 etc don't mention the use case? It
      =   seems to me
            =  that if we include references to use cases that we = should
        be consistent.

  =       [MB] Not all requirements can be mapped directly to = use cases -
        e.g.,
      =   16, 17 & 18. In the cases, where they can, we probably = should. The
        references are intended to = informative. [/MB]


            =  3) REQMT-12: Rather than say "..more than two = <sites>"
        should we = use
             "..more than = two endpoints". We don't have a definition for
    =     "site".

        [MB] = We don't have an explicit definition but it can certainly be
  =       derived from the context. We use "site" = in several other places
        and = just
        replacing that with endpoint in = those cases won't work - e.g,. in
        Section = 4:  "If Alice and Bob are at different sites, Alice needs = to
        tell Bob about the camera and sound = equipment arrangement at her
        site = so
        that Bob's receiver can create an = accurate rendering of her site."
        = That all said, I think we can replace the use of "site" in = that
        requirement as that's consistent = with all the other requirements.
        = [/MB]


             4) = General: Do we need to have some text in the document that
  =            indicates that there may be = other unspecified requirements
        that = may
             be implemented? = The framework has a number of attributes
        = that aren't
             mentioned = as part of the requirements e.g. scene
        = description. Or
            =  alternatively do we capture this by adding a generic
  =       requirement
          =    regarding description of the content of captures/scenes? = The
             requirements are = very focussed on spatial/render aspects
        = rather than
            =  information pertaining to the selection of captures.

  =       [MB] I do not believe so.  These are the bare = bones requirements
        - if we
  =       don't have functionality to support these then we = haven't done
        our job.
    =        However, the solution can certainly define = additional
        functionality,
  =       that doesn't necessarily map to a specific = requirement.  The
        requirements = should not be specifying all the details of the
      =   attributes
        necessary to support = the use cases - that's the objective of the
      =   framework. Now, if you think there is a general requirement = that's
        missing, certainly you can propose = such. Realistically, requirements
        = documents are starting points to seed the solution work. Once = the
        solution is started unless the WG = thinks a requirement can't be met,
        it's = not necessarily productive to try to make the requirements
  =       document
        absolutely = complete.  Indeed, a number of WGs actually never publish
  =       requirements documents, but rather just cache them = in an
        appendix for
    =     historical purposes. [/MB]


      =        5) General: There seems to be a requirement = in CLUE of the
        ability
    =          to indicate how captures are related = to resources. e.g. the STS
            =  mechanism indicates which captures may be used together = (which
             indicates = which ones can't be used together) and the CSE
      =   that groups
            =  capture resources. This seems to be an important aspect = of
        CLUE but
      =        there doesn't appear to be a requirement = driving it.

        [MB] As I mentioned = previously, we don't need to have a
        = requirement to
        justify every aspect of = the solution.   We don't want to get
        = into having
        to define capture scene = entries, etc. in the requirements.   We
      =   don't
        need to backwards engineer = the requirements to match the
        solution. =  [/MB]


            =  Regards, Christian


          =    On 16/09/2013 5:32 AM, Paul Kyzivat wrote:

  =                We started WGLC = on the requirements two weeks ago.
          =        It has run for two weeks, and there have been = *NO*
        comments!!! :-(

    =              I can't advance this = document without better indication of
        =          support from the WG. So I'm extending = this WGLC. I'll
        be away
    =              next weekend, so I will = let this extension run another two
          =        weeks, ending Sunday Sept 29.

  =                We NEED NEED NEED = your comments on this. Please review
        it = again,
                =  and respond either positively or negatively, whether
  =       you think
          =        it is ready to progress.

    =                   = Thanks,
                =       Paul

          =        On 9/2/13 3:50 PM, Paul Kyzivat = wrote:

                =      With this message I'm announcing the start of WGLC = for

      =               =  draft-ietf-clue-telepresence-____requirements-05




          =            This WGLC will last for roughly = two weeks, ending at
              =        midnight GMT on
      =                Sunday September = 15.

                =      It is important to have decisive results from a = WGLC.
                  =    (Silence doesn't do it.)
        =              So please, take a last = careful look at these
        = requirements
                =      and comment.
          =            If you like these as they are, = please say so.

              =              Thanks,
    =                     =    Paul (as co-chair)

        =              On 8/30/13 6:39 PM, internet-drafts@ietf.org
      =   <mailto:internet-drafts@ietf.org>

              =        <mailto:internet-drafts@ietf.__org


    =     <mailto:internet-drafts@ietf.org>> = wrote:


              =            A New Internet-Draft is = available from the on-line
            =             =  Internet-Drafts
            =              directories.
  =                     =       This draft is a work item of the = ControLling
        mUltiple
    =                     =  streams for
              =            tElepresence Working Group of = the IETF.

                =               Title     =       : Requirements for
        = Telepresence
                =          Multi-Streams
      =                     =     Author(s)       : Allyn Romanow
  =                     =                     =            Stephen Botzko
    =                     =                     =          Mary Barnes
      =                     =     Filename       =  :

      =   = draft-ietf-clue-telepresence-____requirements-05.txt

<= p class=3DMsoNormal>

            =                   Pages =           : 13
        =                     =   Date            : = 2013-08-30

              =            Abstract:
    =                     =       This memo discusses the requirements for = a
                  =        specification that enables
    =                     =       telepresence interoperability, by
    =     describing the
          =                relationship = between
                =               multiple RTP streams. =  In addition, the
        problem
  =                     =    statement and
            =                   = definitions are also covered herein.


      =                    The = IETF datatracker status page for this draft is:

        https://datatracker.ietf.org/____doc/draft-ietf-clue-__= __telepresence-requirements
        <https://datatracker.ietf.org/__doc/draft-ietf-clue-__te= lepresence-requirements>




        <https://datatracker.ietf.org/__doc/draft-ietf-clue-__te= lepresence-requirements
        <https://datatracker.ietf.org/doc/draft-ietf-clue-telepr= esence-requirements>>



      =                   =  There's also a htmlized version available = at:

        = http://tools.ietf.org/html/____draft-ietf-clue-telepres= ence-____requirements-05
        <http://tools.ietf.org/html/__draft-ietf-clue-telepresen= ce-__requirements-05>




        <http://tools.ietf.org/html/__draft-ietf-clue-telepresen= ce-__requirements-05
        <http://tools.ietf.org/html/draft-ietf-clue-telepresence= -requirements-05>>

          =                A diff from the = previous version is available at:

        http://www.ietf.org/rfcdiff?____url2=3Ddraft-ietf-clue-= ____telepresence-requirements-05
        = <http://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__= telepresence-requirements-05>




        <http://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__= telepresence-requirements-05
        <http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-tele= presence-requirements-05>>




    =                     =  Please note that it may take a couple of
      =   minutes from
              =            the time of
    =                     =  submission
              =            until the htmlized version and = diff are
        available = at

        = tools.ietf.org = <http://tools.ietf.org> <http://tools.ietf.org>.




            =              Internet-Drafts are also = available by anonymous
        FTP = at:

        = ftp://ftp.ietf.org/internet-____drafts/
  =       <ftp://ftp.ietf.org/internet-__drafts/>
 =                     =    <ftp://ftp.ietf.org/internet-__drafts/
  =       <ftp://ftp.ietf.org/internet-drafts/>>

=                     =     =  ___________________________________________________
  =                     =    clue mailing list
        clue@ietf.org = <mailto:clue@ietf.org> <mailto:clue@ietf.org
        = <mailto:clue@ietf.org>>
      =   https://www.ietf.org/mailman/____listinfo/clue
&= nbsp;       <https://www.ietf.org/mailman/__listinfo/clue>                    =      <https://www.ietf.org/mailman/__listinfo/clue
&nb= sp;       <https://www.ietf.org/mailman/listinfo/clue>><= br>

                =     =  ___________________________________________________
  =                   =  clue mailing list
        clue@ietf.org = <mailto:clue@ietf.org> <mailto:clue@ietf.org
        = <mailto:clue@ietf.org>>
      =   https://www.ietf.org/mailman/____listinfo/clue
&= nbsp;       <https://www.ietf.org/mailman/__listinfo/clue>                    =  <https://www.ietf.org/mailman/__listinfo/clue
&nb= sp;       <https://www.ietf.org/mailman/listinfo/clue>><= br>

                =  ___________________________________________________
  =                clue mailing = list
        clue@ietf.org <mailto:clue@ietf.org> = <mailto:clue@ietf.org
        = <mailto:clue@ietf.org>>
      =   https://www.ietf.org/mailman/____listinfo/clue
&= nbsp;       <https://www.ietf.org/mailman/__listinfo/clue>                 <https://www.ietf.org/mailman/__listinfo/clue
&nb= sp;       <https://www.ietf.org/mailman/listinfo/clue>><= br>

            =  ___________________________________________________
  =            clue mailing list
  =       clue@ietf.org <mailto:clue@ietf.org> = <mailto:clue@ietf.org
        = <mailto:clue@ietf.org>>
      =   https://www.ietf.org/mailman/____listinfo/clue
&= nbsp;       <https://www.ietf.org/mailman/__listinfo/clue>


          =    <https://www.ietf.org/mailman/__listinfo/clue
&nb= sp;       <https://www.ietf.org/mailman/listinfo/clue>><= br>



        = _________________________________________________
    =     clue mailing list
        clue@ietf.org = <mailto:clue@ietf.org>
        = https://www.ietf.org/mailman/__listinfo/clue
&nb= sp;       <https://www.ietf.org/mailman/listinfo/clue>
<= br>
    = _________________________________________________
    clue = mailing list
    clue@ietf.org <mailto:clue@ietf.org>
    https://www.ietf.org/mailman/__listinfo/clue
&nb= sp;   <https://www.ietf.org/mailman/listinfo/clue>
<= br>

 

 

------=_NextPart_001_0012_01CEB44C.7D035E50-- ------=_NextPart_000_0011_01CEB44C.7D035E50 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDkx ODEyNTMwNFowIwYJKoZIhvcNAQkEMRYEFP4TcRyE6TDSnX3EjKXwKUNaYDWbMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAYUIjsHSe5qT7PBgj4ceIXCWfErJRfbkP8nM43U2b wD3Sdk8cEILJGDW77lcbU7iGbEyi819qfdQqkLWuDfKkP1hCx6kwrtLWxbWjK0DCuKJIyeJPFNBz oyN1Nw4aplR9v69mUB5EHFt8CJ03nBPlWGoX2RCc8ySDwipz3WXD11jlS/YZUZRgb56IsqPfvPcy ptua5TSKiClSQhovCBnvYD8h3TMs3buJ/v/n0nu5/hzJ5eWt24cd7WJGS2iNybLBAO41ck28JFFP WetidIMVc7eNsqhmuo4yjLEXcf9q7jN1mR0ExiDAnMP10qSQqgZ5jP4x1nyM2WWJ1Y28W+krNAAA AAAAAA== ------=_NextPart_000_0011_01CEB44C.7D035E50-- From gsalguei@cisco.com Thu Sep 19 09:20:15 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C91021F99E1; Thu, 19 Sep 2013 09:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16g0FutdFak4; Thu, 19 Sep 2013 09:20:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EE02A21F9473; Thu, 19 Sep 2013 09:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2309; q=dns/txt; s=iport; t=1379607603; x=1380817203; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=78pf1f4rXg9h4+xiOCLrgVnae7zD9vKkd/pE+K5XbXo=; b=bGlstCdVpnN9ceKE/WvjihDXTLARfeoBmUjsR4MW0cMyGb253PcVBEn9 CK+nZKWlipJhdQk4Y/6Wp2zeZiisUx93WeYz8Bf0l3qIjUw6RI0TitXGA iB/Gg0OZ6kakUbf96vwP59E0u1PnlGgKgQ3EGDNGKQfgE2N9e4uwtVJxA Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIQjO1KtJV2c/2dsb2JhbABbgwc4TMEygSIWdIIlAQEBAwEBAQE3NAQMCwIBCBgeECcLJQIEARIJh3QGBwW6F480NQWDHoEAA5d8gS+LFoUwgyQ X-IronPort-AV: E=Sophos;i="4.90,937,1371081600"; d="scan'208";a="261984266" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 19 Sep 2013 16:20:02 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8JGK1Jo031813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 16:20:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.21]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 11:20:01 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "clue@ietf.org" , "rtcweb@ietf.org" Thread-Topic: I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt Thread-Index: AQHOtUhFDQQt1kchvUGOM9R/xaYmXpnNPZxE Date: Thu, 19 Sep 2013 16:20:00 +0000 Message-ID: <6EDBE2F4-6722-45EB-A83E-8FDC51DD6633@cisco.com> References: <20130919145505.32671.33449.idtracker@ietfa.amsl.com> In-Reply-To: <20130919145505.32671.33449.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 19 Sep 2013 17:12:55 -0700 Subject: Re: [clue] I-D Action: draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 16:20:15 -0000 [Please forgive the cross-post...] Significant changes have been made to the draft, please provide feedback or= comment on its usefulness @AVTEXT Cheers,=20 Gonzalo > On Sep 19, 2013, at 10:55 AM, "internet-drafts@ietf.org" wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : A Taxonomy of Grouping Semantics and Mechanisms for = Real-Time Transport Protocol (RTP) Sources > Author(s) : Jonathan Lennox > Kevin Gross > Suhas Nandakumar > Gonzalo Salgueiro > Bo Burman > Filename : draft-lennox-raiarea-rtp-grouping-taxonomy-02.txt > Pages : 40 > Date : 2013-09-19 >=20 > Abstract: > The terminology about, and associations among, Real-Time Transport > Protocol (RTP) sources can be complex and somewhat opaque. This > document describes a number of existing and proposed relationships > among RTP sources, and attempts to define common terminology for > discussing protocol entities and their relationships. >=20 > This document is still very rough, but is submitted in the hopes of > making future discussion productive. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-lennox-raiarea-rtp-grouping-taxono= my >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-lennox-raiarea-rtp-grouping-taxonomy-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-lennox-raiarea-rtp-grouping-taxo= nomy-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From pkyzivat@alum.mit.edu Sun Sep 22 06:08:55 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344CE21F999C for ; Sun, 22 Sep 2013 06:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16G4f+Om-8tO for ; Sun, 22 Sep 2013 06:08:49 -0700 (PDT) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:228]) by ietfa.amsl.com (Postfix) with ESMTP id 60DC121F9FE7 for ; Sun, 22 Sep 2013 06:08:47 -0700 (PDT) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta15.emeryville.ca.mail.comcast.net with comcast id UD6U1m0031ZMdJ4AFD8k3z; Sun, 22 Sep 2013 13:08:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([71.227.89.25]) by omta16.emeryville.ca.mail.comcast.net with comcast id UD8l1m00S0Yp4o78cD8m0d; Sun, 22 Sep 2013 13:08:46 +0000 Message-ID: <523EEBDD.5010900@alum.mit.edu> Date: Sun, 22 Sep 2013 09:08:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379855324; bh=8p+NuQwgVIdZ0jaFrMvTJpdQLyHKUt4R1PEEBZccvXk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=RxBQmxZ/v/cuh5e36px5pvE4wSnVHHFtbg2AarTYau0llLJwMrMSnxEuWJB0Ct+NV 6BXwllrrmmZ0tJ5bdNmyWuRu+OuEa0oP4DR81sV2whZNzM52BO/NCEv91stWKIUXlL fR52fEbaHkdkvrytP1VM6sB5KEB8Gxjvoxue2sFM7yckQCejKfY2KNyDIjnu2MqIy7 eNmwLglJnfj9dwGB1JqqQo987EnyTVYNAk8vV8ol67GNoHXH3Yby2wJk1HgPhz0MNk pvrsCp94Ct5/4U+sL7ZblwDhUpBf7KCKB7u3HVW04w414V26MldplRBfRBcIATcKTr 6iIT4+Va5oDag== Subject: [clue] CLUE Requirements WGLC - *STILL* no comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 13:08:55 -0000 PEOPLE!!! We REALLY, REALLY, REALLY need you to review AND SEND COMMENTS on the requirments document. The document cannot be advanced without them. Do you want CLUE to complete, or not? Thank you for your comments, Paul From pkyzivat@alum.mit.edu Sun Sep 22 06:10:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625DB21F9EDA for ; Sun, 22 Sep 2013 06:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sILes9Dbvbtr for ; Sun, 22 Sep 2013 06:10:43 -0700 (PDT) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8D21F9E9F for ; Sun, 22 Sep 2013 06:10:43 -0700 (PDT) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta01.emeryville.ca.mail.comcast.net with comcast id UCta1m00116AWCUA1DAj8N; Sun, 22 Sep 2013 13:10:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([71.227.89.25]) by omta06.emeryville.ca.mail.comcast.net with comcast id UDAi1m0020Yp4o78SDAiVn; Sun, 22 Sep 2013 13:10:42 +0000 Message-ID: <523EEC51.1010003@alum.mit.edu> Date: Sun, 22 Sep 2013 09:10:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379855443; bh=g7TvFvWnp6iuxc61zX8gfQInpANVd82qILPUwNA3DqQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=acUEBslGiDehWLSrIxHt0zQobXYyfxIHt+4uGCyTyL9Pib25WVWouB/8atDnWHc7O g7wQx7r+tCe/TkxN2gO4eVPWN/iw8HXSQFLUPhzm6X18oiHyKhLpF2ENmxiXXmS2YM yCH8LWI5O2yWdpMEj/y6dkG8+Y7qd0r4jao5g4iK2YTykdutqMSM+pnctojZISExrk CfJm3QbvY70EOL7eebzhb3x7TpDwXhNnDtWr31Xm9d0XSDr2nfnlMtc5u0wXVAVVak ZNBY5X5h9n50GEwlwXEXP6X/3KmIzlbWeOug4ua2k6VFAtM6MX++H6N1sdgUddzROr IemGWv9MsSd/w== Subject: [clue] Design team meeting Tuesday X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 13:10:49 -0000 Yes, we will have a design team call this coming Tuesday, 24-september. I'm planning to use the time to discuss the way forward on signaling, using the slides I had prepared for the interim but never got to. Thanks, Paul From roberta.presta@unina.it Mon Sep 23 06:17:06 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79BB21F9CB0 for ; Mon, 23 Sep 2013 06:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy-VJ1xN99Eh for ; Mon, 23 Sep 2013 06:17:00 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 794AD21F9D89 for ; Mon, 23 Sep 2013 06:17:00 -0700 (PDT) Received: from [127.0.0.1] ([193.206.114.54]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r8NDGqwx024542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Sep 2013 15:16:57 +0200 Message-ID: <52403F44.2060609@unina.it> Date: Mon, 23 Sep 2013 15:16:52 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: multipart/alternative; boundary="------------040708030508050006050603" X-Antivirus: avast! (VPS 130923-0, 23/09/2013), Outbound message X-Antivirus-Status: Clean Subject: [clue] comments to draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 13:17:06 -0000 This is a multi-part message in MIME format. --------------040708030508050006050603 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi all, in the following some comments to the requirements draft. * about the interworking telepresence systems In the Introduction section (page 3, third paragraph), it is stated that the purpose of the document is to provide requirements for enabling interworking between /"SIP-based [RFC3261] telepresence systems"/. We should describe/define here in a more precise way these systems, by saying for example that they are "built upon" centralized SIP-based conferencing systems as defined in RFC4353 (the "conference" definition in the following refers to this RFC). We should explicitely mention that we are not dealing with "signaling agnostic" frameworks, if this is the case, i.e. if we leverage SIP as the only signaling protocol for the basic session management. * about dictating architectural choices In the Introduction section, "/It is not the intention of CLUE to dictate telepresence architectural and implementation choices./" I would propose to erase "architectural choice" and to leave only "implementation choice". The CLUE framework should provide some reference architecture for SIP-based telepresence systems in order to let them interoperate, so I would not say that CLUE is not intended to dictate architectural choice. * "Endpoint" definition "/Endpoints can be anything from multiscreen/multicamera rooms to handheld devices./" I agree that talking about room/site *controllers*, or something similar, it is more appropriate. * about the site characteristics that need to be shared In the Problem statement section, page 6, last paragraph: "/Characteristics may include number, placement, capture/_render angle_, resolution of cameras and _screens_, spatial location and audio mixing parameters of microphones. The telepresence multi-stream work seeks to describe the sender situation in a way that allows the receiver to render it realistically, though it may have a different rendering model than//the sender; and _for the receiver to provide information to the sender in order to help the sender create adequate content for interworking_"/. The last sentence seems to make reference to some rendering features of the receiver (render angles, resolution of screens) and that sounds a bit in contrast with the CLUE philosophy, where the media provider does not care about the rendering capabilities of the media consumer. Minor issues: * "/A telepresence session, requires/", comma to be removed * must vs MUST: there are several "must" that are not capitalized Regards, Roberta --------------040708030508050006050603 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hi all,

in the following some comments to the requirements draft.

  • about the interworking telepresence systems
    In the Introduction section (page 3, third paragraph), it is stated that the purpose of the document is to provide requirements for enabling interworking between "SIP-based [RFC3261] telepresence systems". We should describe/define here in a more precise way these systems, by saying for example that they are "built upon" centralized SIP-based conferencing systems as defined in RFC4353 (the "conference" definition in the following refers to this RFC). We should explicitely mention that we are not dealing with "signaling agnostic" frameworks, if this is the case, i.e. if we leverage SIP as the only signaling protocol for the basic session management.
  • about dictating architectural choices
    In the Introduction section, "It is not the intention of CLUE to dictate telepresence architectural and implementation choices." I would propose to erase "architectural choice" and to leave only "implementation choice". The CLUE framework should provide some reference  architecture for SIP-based telepresence systems in order to let them interoperate, so I would not say that CLUE is not intended to dictate architectural choice.
  • "Endpoint" definition
    "Endpoints can be anything from multiscreen/multicamera rooms to handheld devices."
    I agree that talking about room/site *controllers*, or something similar, it is more appropriate.
  • about the site characteristics that need to be shared
    In the Problem statement section, page 6, last paragraph: "Characteristics may include number, placement, capture/render angle, resolution of cameras and screens, spatial location and audio mixing parameters of microphones. The telepresence multi-stream work seeks to describe the sender situation in a way that allows the receiver to render it realistically, though it may have a different rendering model than the sender; and for the receiver to provide information to the sender in order to help the sender create adequate content for interworking". The last sentence seems to make reference to some rendering features of the receiver (render angles, resolution of screens) and that sounds a bit in contrast with the CLUE philosophy, where the media provider does not care about the rendering capabilities of the media consumer.

Minor issues:
  • "A telepresence session, requires", comma to be removed
  • must vs MUST: there are several "must" that are not capitalized

Regards,

Roberta
--------------040708030508050006050603-- From rohanse2@cisco.com Mon Sep 23 13:08:41 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4EE21F9FAE for ; Mon, 23 Sep 2013 13:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ey+A8P+Vr0FO for ; Mon, 23 Sep 2013 13:08:37 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 95DB421F9FC3 for ; Mon, 23 Sep 2013 13:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3197; q=dns/txt; s=iport; t=1379966916; x=1381176516; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=W3hq5lvfh/Qy0ezpn+WMZAyBRhuYDsYUZlm2EtojVnc=; b=k1pRZQGtSy/5aLmhl9DtkjLcSy17rlSFPPbAQZohd2yPYUjZPalkchOI 6afAtAVDDoXBeJ+Erbxv3wtbYyThrJV00wfj2ki4G40v05+xDnBUyVZGn w0+wNDwmxcQQ88gmBgK3pTgJgppeEtuw2+xEf/X3aLAsRyw/vwrxu8MRD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAHKfQFKQ/khM/2dsb2JhbABZgwc4wXuBIxZ0giUBAQEEAQEBNTYJARELGAkWDwkDAgECARUwEAMGAgEBiAEMvAEEj2yEHgOXfIYyi0WDJTs X-IronPort-AV: E=Sophos;i="4.90,964,1371081600"; d="scan'208";a="18225349" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 23 Sep 2013 20:08:28 +0000 Received: from [10.47.196.64] ([10.47.196.64]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8NK8Q11031456 for ; Mon, 23 Sep 2013 20:08:26 GMT Message-ID: <52409FC5.2040209@cisco.com> Date: Mon, 23 Sep 2013 21:08:37 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <20130915010432.23827.47536.idtracker@ietfa.amsl.com> <52350B4E.2010108@alum.mit.edu> In-Reply-To: <52350B4E.2010108@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] New Version Notification for draft-kyzivat-clue-signaling-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 20:08:41 -0000 Hi Paul, Really glad to see the new document - I had a few questions on the new versioning text. I'm all for only doing the version negotiation at the start of the session (as a mandatory exchange before any other messages can be sent). For version support, I don't see any need to ever renegotiate this mid-session: any cases where the support version changes mid-call I can imagine (eg, silent transfer by a B2BUA) will also necessitate closing and reestablishing the CLUE channel, in which case you perform a fresh version negotiation. I do have more concerns about not being able to renegotiate mid-call when it comes to the options. Options include behaviours as well as just 'what extensions to the protocol do I understand', and behaviours may well change mid-call. For instance, 'mediaProvider' is the currently defined option, and I could well imagine an implementation wanting to change that mid-call. On the other hand, I'm not sure that anything other than the major version requires an actual negotiation, rather than something more declarative. When it comes to the major version, both sides clearly need to agree which to use. However, with the mandate that newer minor versions must be backwards compatible with older minor versions by ignoring new XML elements (and attributes?) does this actually need negotiating? Or can both sides simply state their level of support? Assuming the same rule applies to options when XML changes are involved then that seems like it could be declarative too. If there is no negotiation required then mid-session changes to the options become less painful - it's just a new message to state the options rather than requiring the far end to send messages in response. Rob On 15/09/2013 02:20, Paul Kyzivat wrote: > I just posted an updated version of draft-kyzivat-clue-signaling-05. > The announcement is attached. > > My intent was to incorporate the versioning that I discussed on the team > meeting last Tuesday. In doing so I tried to incorporate comments that I > got at the meeting and after. > > As I did it, I found I couldn't avoid making other changes. > In particular, the specification of message responses needed updating, > and I captured some other agreements we have made along the way. > And this forced me to reorganize things. > > The schema has been changed to incorporate the versioning messages, and > changes in responses. > > There is still a lot wrong with this document, but I think it is better. > > There were remaining questions about versioning after the design team > meeting. Now we have a document to refer to when making comments. So > please take a look and comment further about any concerns you may have. > > I need scrutiny on the xml, and on the impact of backward version > compatibility on xml. > > I hope we can talk about this at the interim this coming Tuesday, but it > will depend on people getting a chance to review it before then. > > Thanks, > Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From roberta.presta@unina.it Tue Sep 24 06:35:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E177611E812B for ; Tue, 24 Sep 2013 06:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5wuKkMZOjrv for ; Tue, 24 Sep 2013 06:35:15 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 790FC11E811E for ; Tue, 24 Sep 2013 06:35:13 -0700 (PDT) Received: from [127.0.0.1] ([100.71.17.231]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r8ODZAPp021780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 24 Sep 2013 15:35:11 +0200 Message-ID: <52419510.2050409@unina.it> Date: Tue, 24 Sep 2013 15:35:12 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <523EEC51.1010003@alum.mit.edu> In-Reply-To: <523EEC51.1010003@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130924-0, 24/09/2013), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] Design team meeting Tuesday X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 13:35:22 -0000 ... missing webex details! Can you please provide me with the link? Thank you! Roberta Il 22/09/2013 15:10, Paul Kyzivat ha scritto: > Yes, we will have a design team call this coming Tuesday, 24-september. > I'm planning to use the time to discuss the way forward on signaling, > using the slides I had prepared for the interim but never got to. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From roberta.presta@unina.it Tue Sep 24 08:26:12 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5992821F93F3 for ; Tue, 24 Sep 2013 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJ3UQsNfHntD for ; Tue, 24 Sep 2013 08:26:07 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id DE0F511E8158 for ; Tue, 24 Sep 2013 08:25:17 -0700 (PDT) Received: from [127.0.0.1] ([100.71.17.231]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r8OFPBl2022876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Sep 2013 17:25:12 +0200 Message-ID: <5241AED9.20001@unina.it> Date: Tue, 24 Sep 2013 17:25:13 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paul Kyzivat References: <20130917095554.3962.44448.idtracker@ietfa.amsl.com> <52382850.2020709@unina.it> <523882A1.7070904@alum.mit.edu> In-Reply-To: <523882A1.7070904@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130924-0, 24/09/2013), Outbound message X-Antivirus-Status: Clean Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: New Version Notification for draft-presta-clue-protocol-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:26:12 -0000 Hi Paul, I try to answer in the following. Il 17/09/2013 18:26, Paul Kyzivat ha scritto: > Hi Roberta, > > Thank you for continuing this work. > > I need to consider this revision further regarding the state machine > changes. I'll comment later on those if need be. For the moment I just > want to ask some questions about the extensibility and versioning. You > say: > > Obviously, client and server can not communicate if they do not share > exactly the same XML schema. Such schema will be the one included in > the to-be-written RFC, and associated with the CLUE URN > "urn:ietf:params:xml:ns:clue-message". > > and then, > > When new protocol-specific information are needed somewhere in the > protocol messages, they can be added in place of the elements > and elements envisioned by the protocol schema. The > policy currently defined in the protocol schema for handling > and elements is: > > elementFormDefault="qualified" > > attributeFormDefault="unqualified" > > In that case, the new information must be qualified by namespaces > other than "urn:ietf:params:xml:ns:clue-message" (the protocol URN) > and "urn:ietf:params:xml:ns:clue-info" (the data model URN). > Elements or attributes from unknown namespaces MUST be ignored. > > (And similar logic for data model extensions and addition of new > messages.) > > This implies that every extension defines another schema. Couldn't > that get unpleasant? My quick reading of XMPP leads me to believe that > it allows backward compatible revisions to its schema. (But I don't > fully understand the implications of what it does.) > If you use a new schema that way, for exploiting an extension (a *new* information, or a *new* message - not a *change* to the existent standard stuff), there are no backward compatibility problems. If you do not support the extension, you simply ignore it, but you are able to do all the other standard things. > Another thing - it is certainly everyone's hope that we get everything > right enough the first time that we don't ever require a change that > is not backward compatible. But that doesn't mean we will be > successful at that. > > What would you suggest be done if an incompatible change is required? > Would you just have this detected via a change to the namespace URN? > We have to design the model in order to be able to easily introduce news in a backward compatible way. Non backward compatible changes should be strongly discouraged. While non backward compatible news could be frequent in this starting phase, they should be not in the future, when the standard version will be ready. In this starting phase, we simply change the schema associated to the URN, until we do not share a stable solution. If a completely uncompatible version is designed, then it should replace the existing one - it is always up to implementors to keep the product aligned with the standards. > While I see that could work, with multiple schemas, not all of which > are used in every message, that could mean that an unsupported schema > would not be detected until the clue session is well underway. That > seems undesirable - that we would like to detect incompatibility as > early as possible. We recognize that we have to design a mechanism to signal that a certain extension is not supported and we will working on it. Extensions to data model information and extensions to protocol messages should be treated separately when designing the aforementioned mechanism. > > Also, what about aspects of the protocol other than XML? (For > instance, suppose some future extension is dependent on future > extensions to SDP.) Do you think there should be some *other* > version/extension mechanism for that? > ...That's one of the motivations for keeping as independent as possible CLUE signaling from SDP signaling! > Thanks, > Paul > > > On 9/17/13 6:00 AM, Roberta Presta wrote: >> >> >> Hi all, >> >> we have added in this new version some considerations about protocol >> versioning and extension introduced in the last team call. >> Cheers, >> >> Roberta > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Tue Sep 24 08:31:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA1321F99DE for ; Tue, 24 Sep 2013 08:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gu+5nABQlAY for ; Tue, 24 Sep 2013 08:31:08 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 093C221F960D for ; Tue, 24 Sep 2013 08:31:07 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-96-5241b03a651e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F6.A0.16099.A30B1425; Tue, 24 Sep 2013 17:31:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Tue, 24 Sep 2013 17:31:06 +0200 From: Christer Holmberg To: CLUE Thread-Topic: Is 2nd most active speaker a role? Thread-Index: Ac65Oxa+l4HLcnqYQhawTx6bwHJDQg== Content-Class: urn:content-classes:message Date: Tue, 24 Sep 2013 15:31:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AB149ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvra71Bscgg0kXuCz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPV/DrEXbOevOHPdqYHxG08XIyeHhICJRNPnj2wQtpjEhXvr gWwuDiGBw4wSq0/1skI4SxgltvacZOpi5OBgE7CQ6P6nDdIgIiAhcerUXUYQW1hAW6KrbT0r RNxAounuHyhbT2LZp3ssIDazgJbEjgn7wOpZBFQlln1vYgKxeQV8JS7MbGEGsRmBjvh+ag0T RL24xK0n85kgjhOQWLLnPDOELSrx8vE/VpBzJAQUJZb3y0GU50vsPL6BBWKkoMTJmU9YJjAK z0KyeRaSqbOQtMxC0gIR15O4MXUKG4StLbFs4WtmCFtXYsa/Q1A11hKr5n5nRlazgJFzFSN7 bmJmTnq54SZGYOwc3PJbdwfjqXMihxilOViUxHk36Z0JFBJITyxJzU5NLUgtii8qzUktPsTI xMEp1cCounhn0ZuXy7uapltHX+kWPbygoII1bqLiZ/f+0Ele1envpCR84rb2nFbO/L9/vd5l r1n8kxMD4kU/mfNu0fz2bgq3oaZn0rGCIyuKdWKnsJZ/5syb3PDAxFDO/HWiVdvpfo4VGwxE 7p6MKizcxzGp+f+1hxeXn3nDE9S1+M/Spr97e0/Nm7NRiaU4I9FQi7moOBEAV7Was2sCAAA= Subject: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:31:14 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AB149ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Previously, I gave a comment on the role document, indicating that I would = like to have the possibility to indicate things like "2nd most active speak= er", "3rd most active speaker" etc. Etc it is a dynamic role, which isn't b= ound the role of a physical person, but rather to the system. However, when thinking more about it, I am not sure whether it really fits = the role concept, or whether it should be something else. Do people have comments on this? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4AB149ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <109A25BEF9B76844B64EDD8BD4C013A7@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

Previously, I gave a comment on the role document, indicating that I wou= ld like to have the possibility to indicate things like "2nd most acti= ve speaker", "3rd most active speaker" etc. Etc it is a dyna= mic role, which isn't bound the role of a physical person, but rather to the system.

 

However, when thinking more about it, I am not sure whether it really fi= ts the role concept, or whether it should be something else.

 

Do people have comments on this?

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4AB149ESESSMB209erics_-- From stpeter@stpeter.im Tue Sep 24 08:47:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0B811E8151 for ; Tue, 24 Sep 2013 08:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.434 X-Spam-Level: X-Spam-Status: No, score=-102.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzv0Vcyk0nzH for ; Tue, 24 Sep 2013 08:47:53 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D917F11E8138 for ; Tue, 24 Sep 2013 08:47:31 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E545415DF; Tue, 24 Sep 2013 09:52:41 -0600 (MDT) Message-ID: <5241B412.6050507@stpeter.im> Date: Tue, 24 Sep 2013 09:47:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:47:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/24/13 9:31 AM, Christer Holmberg wrote: > Hi, > > > > Previously, I gave a comment on the role document, indicating that > I would like to have the possibility to indicate things like "2nd > most active speaker", "3rd most active speaker" etc. Etc it is a > dynamic role, which isn't bound the role of a physical person, but > rather to the system. > > > > However, when thinking more about it, I am not sure whether it > really fits the role concept, or whether it should be something > else. > > > > Do people have comments on this? I don't even think most active speaker is a role. IMHO a role is something less dynamic (host, scribe, presenter, etc.), whereas "the two or three people who are producing the most sound right now" is a kind of eventing that doesn't result in changes of roles. Just my centigram of silver... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK bkuiL3QvoacUrL+QXIeW =FRgG -----END PGP SIGNATURE----- From christer.holmberg@ericsson.com Tue Sep 24 08:59:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A358411E8175 for ; Tue, 24 Sep 2013 08:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.655 X-Spam-Level: X-Spam-Status: No, score=-5.655 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yyI-8IcNNMAT for ; Tue, 24 Sep 2013 08:59:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C84DE11E8176 for ; Tue, 24 Sep 2013 08:59:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-8b-5241b6ce9860 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0E.C2.16099.EC6B1425; Tue, 24 Sep 2013 17:59:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Tue, 24 Sep 2013 17:59:10 +0200 From: Christer Holmberg To: Peter Saint-Andre Thread-Topic: [clue] Is 2nd most active speaker a role? Thread-Index: Ac65Oxa+l4HLcnqYQhawTx6bwHJDQv//4wwAgAAkYCz///+U0A== Date: Tue, 24 Sep 2013 15:59:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AB1B1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se>, <5241B412.6050507@stpeter.im> In-Reply-To: <5241B412.6050507@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AB1B1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvre65bY5BBus/yFrsP3WZ2eLYnn5m ByaPJUt+MnnM3fOCOYApissmJTUnsyy1SN8ugSuj4/Mb1oLLJhUfT81jb2A8oNvFyMkhIWAi MeF8BxuELSZx4d56IJuLQ0jgMKPE/w8PGCGcJYwSXw73MXcxcnCwCVhIdP/TBmkQEdCSuHSt jx3EZhaQkFh18QMjiC0sYCYxd+MpVpByEQFzieYVFhDlThKNh6eClbMIqEp8/PcNbC+vgK/E 2x9tYK1CAtkSO9c0gdmcQON7tn0Aq2cEuu37qTVMEKvEJW49mc8EcbOAxJI955khbFGJl4// ga2VEFCUWN4vB1GeL/H+wU9GiFWCEidnPmGZwCg6C8mkWUjKZiEpg4jrSdyYOoUNwtaWWLbw NTOErSsx498hqBprifmdDxiR1Sxg5FjFyJ6bmJmTXm64iREYZwe3/NbdwXjqnMghRmkOFiVx 3k16ZwKFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MFp+0P9+3tmM6UMOWx/bvmxZC7njl1cv qvuffu/f/IUCW38/DZ+868IPj/JI1vp9lmqfelQapBPkXOb+cFiy3P3QV1YD3YOqlTImia2d 696Wbqrkeihtfc0zccs3pq2xr2WD93YvjORWZP43d/OLgtZtYjslZ8v1NDXUb77wZoqy54L6 bVl7vimxFGckGmoxFxUnAgCN40krgQIAAA== Cc: CLUE Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 15:59:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AB1B1ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter, I agree with you - it's not really a role :) That's why I was wondering whether it should be kept separate from the role= draft (obviously I would have to put together a separate draft for it). Regards, Christer ________________________________ From: Peter Saint-Andre [stpeter@stpeter.im] Sent: Tuesday, September 24, 2013 6:47 PM To: Christer Holmberg Cc: CLUE Subject: Re: [clue] Is 2nd most active speaker a role? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/24/13 9:31 AM, Christer Holmberg wrote: > Hi, > > > > Previously, I gave a comment on the role document, indicating that > I would like to have the possibility to indicate things like "2nd > most active speaker", "3rd most active speaker" etc. Etc it is a > dynamic role, which isn't bound the role of a physical person, but > rather to the system. > > > > However, when thinking more about it, I am not sure whether it > really fits the role concept, or whether it should be something > else. > > > > Do people have comments on this? I don't even think most active speaker is a role. IMHO a role is something less dynamic (host, scribe, presenter, etc.), whereas "the two or three people who are producing the most sound right now" is a kind of eventing that doesn't result in changes of roles. Just my centigram of silver... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK bkuiL3QvoacUrL+QXIeW =3DFRgG -----END PGP SIGNATURE----- --_000_7594FB04B1934943A5C02806D1A2204B1C4AB1B1ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <1F1DCA2509AF314D820598983D3EA02D@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

I agree with you - it's not really a role :)

 

That's why I was wondering whether it should be kept separate from the r= ole draft (obviously I would have to put together a separate draft for it).=

 

Regards,

 

Christer

 

From: Peter Saint-Andre [stpeter@stpeter.im]
Sent: Tuesday, September 24, 2013 6:47 PM
To: Christer Holmberg
Cc: CLUE
Subject: Re: [clue] Is 2nd most active speaker a role?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/24/13 9:31 AM, Christer Holmberg wrote:
> Hi,
>
>
>
> Previously, I gave a comment on the role document, indicating that
> I would like to have the possibility to indicate things like "2nd=
> most active speaker", "3rd most active speaker" etc. Et= c it is a
> dynamic role, which isn't bound the role of a physical person, but
> rather to the system.
>
>
>
> However, when thinking more about it, I am not sure whether it
> really fits the role concept, or whether it should be something
> else.
>
>
>
> Do people have comments on this?

I don't even think most active speaker is a role. IMHO a role is
something less dynamic (host, scribe, presenter, etc.), whereas "the two or three people who are producing the most sound right now" is a kind of eventing that doesn't result in changes of roles.

Just my centigram of silver...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http= ://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A
qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe
MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb
AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y
nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H
Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R
ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm
TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU
66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK
bkuiL3QvoacUrL+QXIeW
=3DFRgG
-----END PGP SIGNATURE-----
--_000_7594FB04B1934943A5C02806D1A2204B1C4AB1B1ESESSMB209erics_-- From christer.holmberg@ericsson.com Tue Sep 24 10:57:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4817611E8168 for ; Tue, 24 Sep 2013 10:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.663 X-Spam-Level: X-Spam-Status: No, score=-5.663 tagged_above=-999 required=5 tests=[AWL=0.585, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cu0Ft+IJE-Pf for ; Tue, 24 Sep 2013 10:57:39 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A2A0611E80E3 for ; Tue, 24 Sep 2013 10:57:24 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-7f-5241d282c144 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7D.89.22048.282D1425; Tue, 24 Sep 2013 19:57:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 24 Sep 2013 19:57:19 +0200 From: Christer Holmberg To: CLUE Thread-Topic: Does CLUE data channel failure implicitly trigger fallback to legacy mode? Thread-Index: Ac65T4XBVTijByKeQvuD6Q0zvuf0+Q== Content-Class: urn:content-classes:message Date: Tue, 24 Sep 2013 17:57:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AB2A2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvrW7TJccgg+MLpC32n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOUL+1gKOmUqTracYGlgnCjexcjJISFgInGr8xUrhC0mceHe erYuRi4OIYHDjBK/JxxlhHCWMEo8WrQNyOHgYBOwkOj+pw3SICIgIXHq1F1GEFtYIFRi64uj 7BDxKInfUxaxQdh6Evt3TGUCsZkFtCR2TNgHVs8ioCpxYNFJFhCbV8BXYtfJR2A1jEBHfD+1 BqpeXOLWk/lMEMcJSCzZc54ZwhaVePn4H9TRihIfX+0DO41ZIF/i3B83iJGCEidnPmGZwCg8 C8nmWUimzkLomIWkA6JET+LG1ClsELa2xLKFr5khbF2JGf8OQdVYS2w5/I0dWc0CRs5VjOy5 iZk56eXmmxiBsXNwy2+DHYyb7osdYpTmYFES592sdyZQSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA6PGwhMHt+5fcUfMgPeB7pLKfzW8Bw81tG/I7ryR27Z1tm30cYezEgLTd7d3HxTd5vpa ePf3y59nlSZcC9P/rLnnC8tH8/gQywcV8+uUFNZM/sp9I/Kh79IA20Kezb1F8mo5p22SN5dm T1ppxd1wKWDD4kOG/jLZN3dtTOFoDb8hZG926VVFEIcSS3FGoqEWc1FxIgDe7fhFawIAAA== Subject: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 17:57:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AB2A2ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In CLUE we have been talking about two modes: "legacy mode" and "CLUE mode"= . Without going into the details in this thread, "legacy mode" basically mean= s communication between a CLUE entity and a non-CLUE entity (read: an entit= y that does not support the CLUE protocol). In "CLUE mode", there is a data channel established for the exchange of CLU= E protocol messages. One of the question has been whether a loss of that data channel means an a= utomatic fallback to "legacy mode", or whether a fallback requires an expli= cit Offer, where the data channel is disabled etc. My opinion is that fallback to legacy DOES require an explicit Offer, e.g. = for the following reasons: 1) Make sure that all parties are aware of the fallback. 2) There might be dedicated m=3Daudio/video lines for legacy mode, and duri= ng clue mode they might be disabled. An Offer is needed in order to enable = them. 3) Similar to 2), there are a number of dedicated m=3Daudio/video lines for= clue mode, and when there is a fallback to legacy mode they need to be dis= abled (keeping them enabled might keep unecessary resources locked, and may= also affect charging, etc). Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4AB2A2ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <63D518BA2FB9B3469555B97B81F7678B@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

In CLUE we have been talking about two modes: "legacy mode" an= d "CLUE mode".

 

Without going into the details in this thread, "legacy mode" b= asically means communication between a CLUE entity and a non-CLUE entity (r= ead: an entity that does not support the CLUE protocol).

 

In "CLUE mode", there is a data channel established for the ex= change of CLUE protocol messages.

 

One of the question has been whether a loss of that data channel means a= n automatic fallback to "legacy mode", or whether a fallback requ= ires an explicit Offer, where the data channel is disabled etc.

 

My opinion is that fallback to legacy DOES require an explicit Offer, e.= g. for the following reasons:

 

1) Make sure that all parties are aware of the fallback.

2) There might be dedicated m=3Daudio/video lines for legacy mode, and d= uring clue mode they might be disabled. An Offer is needed in order to enab= le them.

3) Similar to 2), there are a number of dedicated m=3Daudio/video l= ines for clue mode, and when there is a fallback to legacy mode they need t= o be disabled (keeping them enabled might keep unecessary resources locked,= and may also affect charging, etc).

 

Regards,

 

Christer

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4AB2A2ESESSMB209erics_-- From pkyzivat@alum.mit.edu Tue Sep 24 11:37:03 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E6E11E80E4 for ; Tue, 24 Sep 2013 11:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL4kcN+uvbBY for ; Tue, 24 Sep 2013 11:36:57 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D1C7621F9BB6 for ; Tue, 24 Sep 2013 11:36:53 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id UzjA1m0031GhbT8536ctGr; Tue, 24 Sep 2013 18:36:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id V6ct1m00D3ZTu2S3T6ctjo; Tue, 24 Sep 2013 18:36:53 +0000 Message-ID: <5241DBC4.9000506@alum.mit.edu> Date: Tue, 24 Sep 2013 14:36:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380047813; bh=6r50pNZvaRLgOn7dxbO4FC4AjrSJA3dw1joLRbqO6PA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E7H8FJdO3z8wP6YoVOAHrztOzg83KCfZ0np7CwKG/h6dXRr20ejHcyTQ6yEPOKxQ2 960dTQ2jQD6o3De6PTQIXOiHTCpOwVdYnl6YfZ8OW2J5o1lejXLIdAAaumSTT7veYB 7PDjFjTpK0zYJ+eU1vLuVb6YKCkmWGPNYOaHLNsFt4n79m/hJR0jZlH76sYo9qFuY/ tCyOt4FFMU0o6XpiHyPGLdrMbJRDwAnpadlDvi8gS11JZ8ZZcM50AQCp5aYd9q2q3s jxef3q1HBBLVt8rhi/Q218GmjlrA8hu7pwHLuHx3DzdYBn9TkpROJDy7cLmjORbgPP LEC8+3b2mAZzw== Subject: Re: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 18:37:03 -0000 Hi Christer, Thanks for taking this up. One request for you: On 9/24/13 1:57 PM, Christer Holmberg wrote: > Hi, > > In CLUE we have been talking about two modes: "legacy mode" and "CLUE mode". IMO (and Mary's) we need a new name to replace "legacy" mode. "Legacy" has the wrong connotation - of just old stuff that we are trying to get away from. That isn't what we mean here. Rather we mean something like "non-clue mode", but that it too cumbersome. I could live with "clueless mode", though it sounds a bit like a joke. > Without going into the details in this thread, "legacy mode" basically > means communication between a CLUE entity and a non-CLUE entity (read: > an entity that does not support the CLUE protocol). > > In "CLUE mode", there is a data channel established for the exchange of > CLUE protocol messages. > > One of the question has been whether a loss of that data channel means > an automatic fallback to "legacy mode", or whether a fallback requires > an explicit Offer, where the data channel is disabled etc. > > My opinion is that fallback to legacy DOES require an explicit Offer, > e.g. for the following reasons: > > 1) Make sure that all parties are aware of the fallback. > > 2) There might be dedicated m=audio/video lines for legacy mode, and > during clue mode they might be disabled. An Offer is needed in order to > enable them. > > 3) Similar to 2), there are a number of dedicated m=audio/video lines > for clue mode, and when there is a fallback to legacy mode they need to > be disabled (keeping them enabled might keep unecessary resources > locked, and may also affect charging, etc). I agree with all the above. It has been proposed by some that it might be desirable to close the clue channel yet remain in CLUE mode. At least in principle this could work. The last negotiated advertisement and configuration would remain in effect. I guess this would save *some* (small) amount of resources in cases where no changes in clue configuration are anticipated. If we did support this, then we would require an even more overt way to indicate the transition to legacy mode. Personally I don't find this compelling. I'm satisfied with absence or explicit closing of the clue channel as the indicator for legacy mode. But I think we need to get consensus on this. Thanks, Paul From pkyzivat@alum.mit.edu Tue Sep 24 11:46:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE4021F9CA5 for ; Tue, 24 Sep 2013 11:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=1.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKY36NuhXTge for ; Tue, 24 Sep 2013 11:46:30 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8243221F9C8B for ; Tue, 24 Sep 2013 11:46:30 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id UzWB1m0070ldTLk5E6lVDD; Tue, 24 Sep 2013 18:45:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id V6lU1m00w3ZTu2S016lUlz; Tue, 24 Sep 2013 18:45:29 +0000 Message-ID: <5241DDC7.5020608@alum.mit.edu> Date: Tue, 24 Sep 2013 14:45:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> <5241B412.6050507@stpeter.im> In-Reply-To: <5241B412.6050507@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1380048329; bh=gjciS2JlaRxqM4MvRBDrGr36cr/2YDOzDFCIl+NqvQg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IHEImym2Uq53Q7WTWpwlr0i6YWx0u47C+y7I8O6UlwEGEqO0LiJkn2CNszdjpNr7g 4qGwcfZf6zF18tGKLHucmjGiqPnpjKVbZUbiKRpN0mrudgXGrlYdcjo83w8MAXFO2b JJ/PoeGFzCgcM3OFzFgZIem/Ikv4xWyywTX0aos03qt8LO22VudRWvbxpN8ksGDr1M GxpVLYuwd26jh1j/p68CkPyN6DJtG+Alw9df7AncrIV01y2tIqUmRJ7hCVXmwZeed6 YZEbUM7CeEAH29q7BnT7573IWtlTwr5AlolUsbuLDXDc5oQQwdbO8l7wvuBKNIqQg7 DNATaqIemdG9Q== Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2013 18:46:35 -0000 On 9/24/13 11:47 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/24/13 9:31 AM, Christer Holmberg wrote: >> Hi, >> >> Previously, I gave a comment on the role document, indicating that >> I would like to have the possibility to indicate things like "2nd >> most active speaker", "3rd most active speaker" etc. Etc it is a >> dynamic role, which isn't bound the role of a physical person, but >> rather to the system. >> >> However, when thinking more about it, I am not sure whether it >> really fits the role concept, or whether it should be something >> else. >> >> Do people have comments on this? > > I don't even think most active speaker is a role. IMHO a role is > something less dynamic (host, scribe, presenter, etc.), whereas "the > two or three people who are producing the most sound right now" is a > kind of eventing that doesn't result in changes of roles. > > Just my centigram of silver... I agree that we don't want roles that change frequently for a given capture. So attaching this to a capture when speaking, and removing when not is a really bad idea. But "most active speaker" and "second most active speaker" *could* be roles carried by *switched* captures. They would be statically assigned - this switched capture always contains the most active speaker. I'm undecided whether I like that. It could solve some problems for us. What do others think? Thanks, Paul > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A > qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 > /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe > MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb > AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y > nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h > RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H > Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R > ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm > TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU > 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK > bkuiL3QvoacUrL+QXIeW > =FRgG > -----END PGP SIGNATURE----- > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Tue Sep 24 23:42:58 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3300B21F9FB6 for ; Tue, 24 Sep 2013 23:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.672 X-Spam-Level: X-Spam-Status: No, score=-5.672 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQFOI77aPBsH for ; Tue, 24 Sep 2013 23:42:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 808B321F9F50 for ; Tue, 24 Sep 2013 23:42:50 -0700 (PDT) X-AuditID: c1b4fb25-b7eff8e000000eda-fb-524285e8e88a Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 93.71.03802.8E582425; Wed, 25 Sep 2013 08:42:49 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 08:42:48 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? Thread-Index: Ac65T4XBVTijByKeQvuD6Q0zvuf0+f//6YAA//8WMOA= Date: Wed, 25 Sep 2013 06:42:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AB73E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> <5241DBC4.9000506@alum.mit.edu> In-Reply-To: <5241DBC4.9000506@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre7LVqcggw8/mCz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj464tjAXXxSu+HHzL0sD4WKiLkZNDQsBE 4tfZA+wQtpjEhXvr2boYuTiEBA4zSnycdIQZwlnCKPHy+hKgKg4ONgELie5/2iANIgKeEjs+ TmEGsYUFEiSubXrFDhFPlJg4vZERwraSmPb1CSuIzSKgKjHx4lYmEJtXwFdi6uYdYL1CAvkS B9b1g/VyCuhIPL35A6yGEeig76fWgNnMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWxFiZ1n 25kh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkT03MTMn vdxoEyMwFg5u+a26g/HOOZFDjNIcLErivJv1zgQKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YFRT+3DpbpRc1ZoKd57mD2HXRWMaeDZZB4fPWvWl1bZU/+XLqSc7TPfwyE/VZ9ws80mto/rx hNWTslvEzgk1vdjw9Jzc5G2hCwos5Tn29p+L7b63N624mnfzm2J+9YvafsrsEovntWV9KJxx /XJiZ9Iqu9CArrw9vVqvNS8F1QhGVlxrnFr+QImlOCPRUIu5qDgRAFtIe1BTAgAA Subject: Re: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 06:42:58 -0000 Hi, >Thanks for taking this up. One request for you: On 9/24/13 1:57 PM, Christer Holmberg wrote: > Hi, > > In CLUE we have been talking about two modes: "legacy mode" and "CLUE mod= e". > > IMO (and Mary's) we need a new name to replace "legacy" mode. > "Legacy" has the wrong connotation - of just old stuff that we are trying= to get away from. That isn't what we mean here. Rather we=20 > mean something like "non-clue mode", but that it too cumbersome. I could = live with "clueless mode", though it sounds a bit like a joke. Another term that have been used is "single-stream mode". Not sure that is = very good either, though, because in the example I intend to present next w= eek there are actually 4 streams in the non-clue mode :) >> Without going into the details in this thread, "legacy mode" basically=20 >> means communication between a CLUE entity and a non-CLUE entity (read: >> an entity that does not support the CLUE protocol). >> >> In "CLUE mode", there is a data channel established for the exchange=20 >> of CLUE protocol messages. >> >> One of the question has been whether a loss of that data channel means=20 >> an automatic fallback to "legacy mode", or whether a fallback requires=20 >> an explicit Offer, where the data channel is disabled etc. >> >> My opinion is that fallback to legacy DOES require an explicit Offer,=20 >> e.g. for the following reasons: >> >> 1) Make sure that all parties are aware of the fallback. >> >> 2) There might be dedicated m=3Daudio/video lines for legacy mode, and=20 >> during clue mode they might be disabled. An Offer is needed in order=20 >> to enable them. >> >> 3) Similar to 2), there are a number of dedicated m=3Daudio/video lines= =20 >> for clue mode, and when there is a fallback to legacy mode they need=20 >> to be disabled (keeping them enabled might keep unecessary resources=20 >> locked, and may also affect charging, etc). > >I agree with all the above. > > It has been proposed by some that it might be desirable to close the clue= channel yet remain in CLUE mode.=20 > > At least in principle this could work. The last negotiated advertisement = and configuration would remain in effect. I guess=20 > this would save *some* (small) amount of resources in cases where no chan= ges in clue configuration are anticipated. > > If we did support this, then we would require an even more overt way to i= ndicate the transition to legacy mode. > > Personally I don't find this compelling. I'm satisfied with absence or ex= plicit closing of the clue channel as the indicator for legacy mode.=20 > But I think we need to get consensus on this. There may be a number of reason (some of which end users don't have any con= trol over) why a the clue channel goes down, so my opinion is still that ex= plicit closing (read: SDP Offer) is needed. Having said that, if the clue channel does go down, we probably need some t= ext on how to re-establish it. Regards, Christer From christer.holmberg@ericsson.com Wed Sep 25 00:07:25 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBD221F9E6B for ; Wed, 25 Sep 2013 00:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.68 X-Spam-Level: X-Spam-Status: No, score=-5.68 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smzyhzCr8Iuq for ; Wed, 25 Sep 2013 00:07:21 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD2C21F9DF6 for ; Wed, 25 Sep 2013 00:07:19 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-41-52428ba4aae7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E1.A6.22048.4AB82425; Wed, 25 Sep 2013 09:07:16 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 09:07:15 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Is 2nd most active speaker a role? Thread-Index: Ac65Oxa+l4HLcnqYQhawTx6bwHJDQv//4wwAgAAxuID//xV5AA== Date: Wed, 25 Sep 2013 07:07:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AB7F9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> <5241B412.6050507@stpeter.im> <5241DDC7.5020608@alum.mit.edu> In-Reply-To: <5241DDC7.5020608@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvre6Sbqcgg03n9S32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjzVHxgv2iFYfXLWRuYFwg1MXIySEhYCIx ZWMbE4QtJnHh3nq2LkYuDiGBw4wS+343sEI4Sxglfp88xdjFyMHBJmAh0f1PG6RBRMBTYsfH KcwgtrCAmcTcjadYQUpEBMwlmldYQJQ4SSw/dokFJMwioCqx75Q1SJhXwFfiyY1mFojpvYwS X67eYQFJcAroSHxv+sgGYjMC3fP91Bqw25gFxCVuPZkPdaeAxJI955khbFGJl4//sULYihI7 z7YzQ9TrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJm Tnq5+SZGYBwc3PLbYAfjpvtihxilOViUxHk3650JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cDouV33UnnOPU/dUuepx+9wZE/pEf6V/SLE9Wj6scUeHOZ3s17oCUy8tT/tmvLTmtRZ37SD kthaz577zXHy4G2+lwXCs50Sds2dfyNVrSnjWeiWH55HPrO+OJEt2y1h7johd2XGS63z99vM JLbeVJ7Bb+HgtD94z56c2Nrn/xJU1at37kgJSxFXYinOSDTUYi4qTgQAwwr/n1ECAAA= Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 07:07:26 -0000 Hi, >>> Previously, I gave a comment on the role document, indicating that I=20 >>> would like to have the possibility to indicate things like "2nd most=20 >>> active speaker", "3rd most active speaker" etc. Etc it is a dynamic=20 >>> role, which isn't bound the role of a physical person, but rather to=20 >>> the system. >>> >>> However, when thinking more about it, I am not sure whether it really=20 >>> fits the role concept, or whether it should be something else. >>> >>> Do people have comments on this? >> >> I don't even think most active speaker is a role. IMHO a role is=20 >> something less dynamic (host, scribe, presenter, etc.), whereas "the=20 >> two or three people who are producing the most sound right now" is a=20 >> kind of eventing that doesn't result in changes of roles. >> >> Just my centigram of silver... > > I agree that we don't want roles that change frequently for a given captu= re. So attaching this to a capture when speaking, and removing when not is = a really bad idea. > > But "most active speaker" and "second most active speaker" *could* be rol= es carried by *switched* captures. They would be statically assigned > - this switched capture always contains the most active speaker. > > I'm undecided whether I like that. It could solve some problems for us. > > What do others think? I sounds reasonable to me. Regards, Christer > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A > qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 > /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe > MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb > AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y > nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h > RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H > Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R > ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm > TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU > 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK > bkuiL3QvoacUrL+QXIeW > =3DFRgG > -----END PGP SIGNATURE----- > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Wed Sep 25 00:39:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E5021F9FAC for ; Wed, 25 Sep 2013 00:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQry3OsvXs83 for ; Wed, 25 Sep 2013 00:39:48 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id D6E3A21F9FAB for ; Wed, 25 Sep 2013 00:39:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBADSSQlJ20ZLF/2dsb2JhbAANTYM/wReBMoMZAQEBBAEBATUbFAcKEQsYCRYPCQMCAQIBFTATBgIBAYgOqBqTLI9YhB0DmSuTfg Received: from ppp118-209-146-197.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.146.197]) by ipmail06.adl6.internode.on.net with ESMTP; 25 Sep 2013 17:09:45 +0930 Message-ID: <52429331.1090909@nteczone.com> Date: Wed, 25 Sep 2013 17:39:29 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> <5241B412.6050507@stpeter.im> <5241DDC7.5020608@alum.mit.edu> In-Reply-To: <5241DDC7.5020608@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 07:39:49 -0000 Hello Christer, I don't think "most active, second most active, etc" really fit what roles are about. To me they're more related to switching and switching policy. To me they seem to be an attribute related to a switched capture. I.e. the capture is switched to always show the most active speaker, etc. This fits with what I have been trying to do with my multiple content capture draft. Using the example of MCC that I previously posted to the list, a possible implementation could be: CapScene9[Description=Output9streams, MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy=most_active_speaker}{Encodinggroup4} MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy=2nd_active_speaker}{Encodinggroup5} etc. This would indicate that MCC4 would contain the most active speaker from source captures VC4 to VC15 and MCC5 would contain the 2nd active speaker from source captures VC4 to VC15. If a consumer only wanted to see the most active speaker it would only select MCC4. Regards, Christian On 25/09/2013 4:45 AM, Paul Kyzivat wrote: > On 9/24/13 11:47 AM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/24/13 9:31 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Previously, I gave a comment on the role document, indicating that >>> I would like to have the possibility to indicate things like "2nd >>> most active speaker", "3rd most active speaker" etc. Etc it is a >>> dynamic role, which isn't bound the role of a physical person, but >>> rather to the system. >>> >>> However, when thinking more about it, I am not sure whether it >>> really fits the role concept, or whether it should be something >>> else. >>> >>> Do people have comments on this? >> >> I don't even think most active speaker is a role. IMHO a role is >> something less dynamic (host, scribe, presenter, etc.), whereas "the >> two or three people who are producing the most sound right now" is a >> kind of eventing that doesn't result in changes of roles. >> >> Just my centigram of silver... > > I agree that we don't want roles that change frequently for a given > capture. So attaching this to a capture when speaking, and removing > when not is a really bad idea. > > But "most active speaker" and "second most active speaker" *could* be > roles carried by *switched* captures. They would be statically > assigned - this switched capture always contains the most active speaker. > > I'm undecided whether I like that. It could solve some problems for us. > > What do others think? > > Thanks, > Paul > >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A >> qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 >> /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe >> MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb >> AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y >> nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h >> RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H >> Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R >> ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm >> TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU >> 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK >> bkuiL3QvoacUrL+QXIeW >> =FRgG >> -----END PGP SIGNATURE----- >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Sep 25 03:55:11 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B3C21F9E4F for ; Wed, 25 Sep 2013 03:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pct9KGQHkodo for ; Wed, 25 Sep 2013 03:55:09 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 0AEE321F9E40 for ; Wed, 25 Sep 2013 03:55:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBACXAQlJ20ZLF/2dsb2JhbAANRgiDP8EOCYE0gxkBAQEDAQEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBh3wSqFGTLASOFIFEhB0DlB+XOoFQ Received: from ppp118-209-146-197.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.146.197]) by ipmail06.adl6.internode.on.net with ESMTP; 25 Sep 2013 20:25:06 +0930 Message-ID: <5242C0FA.1010209@nteczone.com> Date: Wed, 25 Sep 2013 20:54:50 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> <5241DBC4.9000506@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4AB73E@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AB73E@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 10:55:12 -0000 Hello, Please see my comments below. Christian On 25/09/2013 4:42 PM, Christer Holmberg wrote: > Hi, > >> Thanks for taking this up. One request for you: > On 9/24/13 1:57 PM, Christer Holmberg wrote: >> Hi, >> >> In CLUE we have been talking about two modes: "legacy mode" and "CLUE mode". >> >> IMO (and Mary's) we need a new name to replace "legacy" mode. >> "Legacy" has the wrong connotation - of just old stuff that we are trying to get away from. That isn't what we mean here. Rather we >> mean something like "non-clue mode", but that it too cumbersome. I could live with "clueless mode", though it sounds a bit like a joke. > Another term that have been used is "single-stream mode". Not sure that is very good either, though, because in the example I intend to present next week there are actually 4 streams in the non-clue mode :) [CNG] In Q.5/16 in the requirements document we have a legacy use case as well as requirements for interworking to legacy devices. I think the term is fine. We could always add a definition somewhere if its unclear. > >>> Without going into the details in this thread, "legacy mode" basically >>> means communication between a CLUE entity and a non-CLUE entity (read: >>> an entity that does not support the CLUE protocol). >>> >>> In "CLUE mode", there is a data channel established for the exchange >>> of CLUE protocol messages. >>> >>> One of the question has been whether a loss of that data channel means >>> an automatic fallback to "legacy mode", or whether a fallback requires >>> an explicit Offer, where the data channel is disabled etc. >>> >>> My opinion is that fallback to legacy DOES require an explicit Offer, >>> e.g. for the following reasons: >>> >>> 1) Make sure that all parties are aware of the fallback. >>> >>> 2) There might be dedicated m=audio/video lines for legacy mode, and >>> during clue mode they might be disabled. An Offer is needed in order >>> to enable them. >>> >>> 3) Similar to 2), there are a number of dedicated m=audio/video lines >>> for clue mode, and when there is a fallback to legacy mode they need >>> to be disabled (keeping them enabled might keep unecessary resources >>> locked, and may also affect charging, etc). >> I agree with all the above. >> >> It has been proposed by some that it might be desirable to close the clue channel yet remain in CLUE mode. >> >> At least in principle this could work. The last negotiated advertisement and configuration would remain in effect. I guess >> this would save *some* (small) amount of resources in cases where no changes in clue configuration are anticipated. >> >> If we did support this, then we would require an even more overt way to indicate the transition to legacy mode. >> >> Personally I don't find this compelling. I'm satisfied with absence or explicit closing of the clue channel as the indicator for legacy mode. >> But I think we need to get consensus on this. > There may be a number of reason (some of which end users don't have any control over) why a the clue channel goes down, so my opinion is still that explicit closing (read: SDP Offer) is needed. > > Having said that, if the clue channel does go down, we probably need some text on how to re-establish it. [CNG] I think Paul is referring to me when he says "some". This was in the context of what does it actually mean to the media if the CLUE data channel is closed? If the CLUE data channel is closed it doesn't automatically mean that the media is removed or that the encoding of the media changes. The media is only removed or changed via SDP. So you can remove the CLUE data channel but the media established as a result of a CLUE exchange remains. What do we assume about the metadata (i.e. CLUE attributes) regarding those streams? i.e. is the spatial information valid or no longer valid, etc? Does the removal or the CLUE data channel only give a legacy state? or is the legacy mode reverting back to media that would have been established in the absence of CLUE support? For me legacy would be the later. > > Regards, > > Christer > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From christer.holmberg@ericsson.com Wed Sep 25 04:37:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99511E80DE for ; Wed, 25 Sep 2013 04:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.688 X-Spam-Level: X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc-SNeiHveZs for ; Wed, 25 Sep 2013 04:37:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 61B7A11E8107 for ; Wed, 25 Sep 2013 04:37:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-c0-5242caf45f9a Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 5F.29.16099.4FAC2425; Wed, 25 Sep 2013 13:37:24 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 13:37:23 +0200 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Is 2nd most active speaker a role? Thread-Index: Ac65Oxa+l4HLcnqYQhawTx6bwHJDQv//4wwAgAAxuICAANhDgP//nGSQ Date: Wed, 25 Sep 2013 11:37:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4ABBD7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> <5241B412.6050507@stpeter.im> <5241DDC7.5020608@alum.mit.edu> <52429331.1090909@nteczone.com> In-Reply-To: <52429331.1090909@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre6XU05BBss7RSy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXxv3clS8EllYreF3fYGhify3UxcnJICJhI vNnayQRhi0lcuLeerYuRi0NI4DCjxLY7u5ggnCWMEkcmvWfuYuTgYBOwkOj+pw3SICIQLtGx 7QojiC0sYCYxd+MpVpASEQFzieYVFhAlbhJ/L9xgB7FZBFQlJp74xgxi8wr4SkyYv4MVYvx6 Rom3Z++BHcEpoCMx6dh2NhCbEeig76fWgMWZBcQlbj2ZD3WogMSSPeeZIWxRiZeP/7FC2IoS O8+2M0PU60gs2P2JDcLWlli28DXUYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFSN7bmJm Tnq54SZGYCwc3PJbdwfjqXMihxilOViUxHk36Z0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cCYmu16Z4ZExt8TJrvNJJN+mvyX79ASNTlgprbR+qCR+wFG8dMLomxltwp47Tpj1Mt7eP/O u4Wv0iq/V1fPbasQKAllz3m1LutGGf+2TYW6/tcNVJQPCu4Xf3BS987ZbWHFWgXs68o0LI/P 4NhY5+EUdmbLklkBLbZ2x0XMWq9Fppj4xiwVUVViKc5INNRiLipOBABSxjqqUwIAAA== Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 11:37:34 -0000 Hi Christian, After a first look, your proposal looks ok. I DO have some comments about, for a given MCC, list all associated VCs, bu= t I'll deal with that in a separate thread :) Regards, Christer -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= istian Groves Sent: 25. syyskuuta 2013 10:39 To: clue@ietf.org Subject: Re: [clue] Is 2nd most active speaker a role? Hello Christer, I don't think "most active, second most active, etc" really fit what roles = are about. To me they're more related to switching and switching policy. To= me they seem to be an attribute related to a switched capture. I.e. the ca= pture is switched to always show the most active speaker, etc. This fits with what I have been trying to do with my multiple content captu= re draft. Using the example of MCC that I previously posted to the list, a possible i= mplementation could be: CapScene9[Description=3DOutput9streams, MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy=3Dmost_active_speaker}{Encodinggroup4} MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, VC14,VC15){MaxCaptures:1}{Policy=3D2nd_active_speaker}{Encodinggroup5} etc. This would indicate that MCC4 would contain the most active speaker from so= urce captures VC4 to VC15 and MCC5 would contain the 2nd active speaker fro= m source captures VC4 to VC15. If a consumer only wanted to see the most ac= tive speaker it would only select MCC4. Regards, Christian On 25/09/2013 4:45 AM, Paul Kyzivat wrote: > On 9/24/13 11:47 AM, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 9/24/13 9:31 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Previously, I gave a comment on the role document, indicating that I=20 >>> would like to have the possibility to indicate things like "2nd most=20 >>> active speaker", "3rd most active speaker" etc. Etc it is a dynamic=20 >>> role, which isn't bound the role of a physical person, but rather to=20 >>> the system. >>> >>> However, when thinking more about it, I am not sure whether it=20 >>> really fits the role concept, or whether it should be something=20 >>> else. >>> >>> Do people have comments on this? >> >> I don't even think most active speaker is a role. IMHO a role is=20 >> something less dynamic (host, scribe, presenter, etc.), whereas "the=20 >> two or three people who are producing the most sound right now" is a=20 >> kind of eventing that doesn't result in changes of roles. >> >> Just my centigram of silver... > > I agree that we don't want roles that change frequently for a given=20 > capture. So attaching this to a capture when speaking, and removing=20 > when not is a really bad idea. > > But "most active speaker" and "second most active speaker" *could* be=20 > roles carried by *switched* captures. They would be statically=20 > assigned - this switched capture always contains the most active speaker. > > I'm undecided whether I like that. It could solve some problems for us. > > What do others think? > > Thanks, > Paul > >> Peter >> >> - -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A >> qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 >> /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe >> MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb >> AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y >> nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h >> RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H >> Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R >> ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm >> TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU >> 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK >> bkuiL3QvoacUrL+QXIeW >> =3DFRgG >> -----END PGP SIGNATURE----- >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Wed Sep 25 04:46:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14F21F9983 for ; Wed, 25 Sep 2013 04:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.87 X-Spam-Level: X-Spam-Status: No, score=-3.87 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff9KnqTnKUXX for ; Wed, 25 Sep 2013 04:46:30 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id BB92321F937E for ; Wed, 25 Sep 2013 04:46:25 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-65-5242cd0bf0f0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1D.EA.25272.B0DC2425; Wed, 25 Sep 2013 13:46:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0328.009; Wed, 25 Sep 2013 13:46:18 +0200 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? Thread-Index: Ac65T4XBVTijByKeQvuD6Q0zvuf0+f//6YAA//8WMOCAAfsNAP//0m9A Date: Wed, 25 Sep 2013 11:46:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4ABC04@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> <5241DBC4.9000506@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4AB73E@ESESSMB209.ericsson.se> <5242C0FA.1010209@nteczone.com> In-Reply-To: <5242C0FA.1010209@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvrS73Wacgg70btCy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJVx+nJ4wQLVij93n7A0MD6T7WLk4JAQMJF4 sEiwi5ETyBSTuHBvPRuILSRwlFHiSGN0FyMXkL2EUWLa+2ksIPVsAhYS3f+0QWpEBMIlOrZd YQSxhQUSJK5tesUOEU+UmDi9kRHCdpPoPXWFBcRmEVCVmHX0NVgNr4CvxNTOn6wQ868ySjzp aWYGSXAK6Eg8+rMTrIgR6KDvp9YwgdjMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YIWxFiZ1n 25kh6nUkFuz+xAZha0ssW/iaGWKxoMTJmU9YJjCKzkIydhaSlllIWmYhaVnAyLKKkaM4tTgp N93IYBMjMBIObvltsYPx8l+bQ4zSHCxK4rxb9M4ECgmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amD087wXE9Ycs8x0dpFEFZsymxWLdYbShtwDN8Tbl59hfVFaePSixMRnG0zXqdydaCkpIi8z +5GGWieHgMXKm9GiLum/bV3PPN62bp3gnpmzxDSYIh39trHmOywoVthRufzyhb9/V+dGft33 Ifi2y5LEiG93+H/JiPd48jycwPCsze3ecud9HlFKLMUZiYZazEXFiQD0RArMUgIAAA== Subject: Re: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 11:46:35 -0000 Hi, >>> In CLUE we have been talking about two modes: "legacy mode" and "CLUE m= ode". >>> >>> IMO (and Mary's) we need a new name to replace "legacy" mode. >>> "Legacy" has the wrong connotation - of just old stuff that we are=20 >>> trying to get away from. That isn't what we mean here. Rather we mean s= omething like "non-clue mode", but that it too cumbersome. I could live wit= h "clueless mode", though it sounds a bit like a joke. >> Another term that have been used is "single-stream mode". Not sure=20 >> that is very good either, though, because in the example I intend to=20 >> present next week there are actually 4 streams in the non-clue mode :) > [CNG] In Q.5/16 in the requirements document we have a legacy use case as= well as requirements for interworking to legacy devices. I think the term = is fine. We could always add a definition somewhere if its unclear. Does Q.5/16 have a definition that we could use? >>>> Without going into the details in this thread, "legacy mode"=20 >>>> basically means communication between a CLUE entity and a non-CLUE ent= ity (read: >>>> an entity that does not support the CLUE protocol). >>>> >>>> In "CLUE mode", there is a data channel established for the exchange=20 >>>> of CLUE protocol messages. >>>> >>>> One of the question has been whether a loss of that data channel=20 >>>> means an automatic fallback to "legacy mode", or whether a fallback=20 >>>> requires an explicit Offer, where the data channel is disabled etc. >>>> >>>> My opinion is that fallback to legacy DOES require an explicit=20 >>>> Offer, e.g. for the following reasons: >>>> >>>> 1) Make sure that all parties are aware of the fallback. >>>> >>>> 2) There might be dedicated m=3Daudio/video lines for legacy mode, and= =20 >>>> during clue mode they might be disabled. An Offer is needed in order=20 >>>> to enable them. >>>> >>>> 3) Similar to 2), there are a number of dedicated m=3Daudio/video=20 >>>> lines for clue mode, and when there is a fallback to legacy mode=20 >>>> they need to be disabled (keeping them enabled might keep unecessary=20 >>>> resources locked, and may also affect charging, etc). >>> I agree with all the above. >>> >>> It has been proposed by some that it might be desirable to close the cl= ue channel yet remain in CLUE mode. >>> >>> At least in principle this could work. The last negotiated=20 >>> advertisement and configuration would remain in effect. I guess this wo= uld save *some* (small) amount of resources in cases where no changes in cl= ue configuration are anticipated. >>> >>> If we did support this, then we would require an even more overt way to= indicate the transition to legacy mode. >>> >>> Personally I don't find this compelling. I'm satisfied with absence or = explicit closing of the clue channel as the indicator for legacy mode. >>> But I think we need to get consensus on this. >> There may be a number of reason (some of which end users don't have any = control over) why a the clue channel goes down, so my opinion is still that= explicit closing (read: SDP Offer) is needed. >> >> Having said that, if the clue channel does go down, we probably need som= e text on how to re-establish it. > > [CNG] I think Paul is referring to me when he says "some". This was in th= e context of what does it actually mean to the media if the=20 > CLUE data channel is closed? If the CLUE data channel is closed it doesn'= t automatically mean that the media is removed or that the encoding=20 > of the media changes. The media is only removed or changed via SDP. So yo= u can remove the CLUE data channel but the media established as a=20 > result of a CLUE exchange remains. What do we assume about the metadata (= i.e. CLUE attributes) regarding those streams? i.e. is the spatial=20 > information valid or no longer valid, etc? My idea is that, in legacy mode, we only have a single audio stream, two vi= deo streams (of which one is for presentation/screen sharing), so there is = no need for spatial information.=20 If you want to exchange spatial information - you use CLUE.=20 > Does the removal or the CLUE data channel only give a legacy state? or is= the legacy mode reverting back to media that would have been established i= n the absence of CLUE support? In my opinion, there is no "that would have been established". In the rever= ting-back-to-legacy SDP Offer, you need to explicitly negotiate the media y= ou are going to use, the same way you do when you send the initial Offer fo= r the session. Regards, Christer _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mrducky@gmail.com Wed Sep 25 04:59:39 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB0721F9F99 for ; Wed, 25 Sep 2013 04:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBr5zryWyhGk for ; Wed, 25 Sep 2013 04:59:39 -0700 (PDT) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DB1F021F9F62 for ; Wed, 25 Sep 2013 04:59:38 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id e12so4337128vbg.15 for ; Wed, 25 Sep 2013 04:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=B3jsMZGdu3zEzTSDhR2d2N41oL0z5u6wpvuo4fVHQVA=; b=pXNYKL8wni6AfMfMCwlM2I8XD76270ADLmP2oEgIsbWuLMn+gS9lE8Oqq7tH6D0e7y 34ot9lsKJUDLmiYeDbBUnSusvhQenjsAKSIcWJrvFxOxRDuN3CZwznxbgbxUM5qVs+FR HELT47GF9d91CGVE4JvEJp+3twIIYzCrij0Z6GbfWAdKmeyHoEIUv3r5rTv9ZEeZIK3s rg4rwiCVe9Mib6ubE2p8WIZS/21Zy2AVEUIs+HsfEANmGXyZRq4YStZyOYcWDtpJ1Eom d8yXrXc4D7ashHKCcSgvZExgF2op2wYrWKYiaDsn3mPFz989rLy4z4wwzhy+mpq1nDQP kACQ== MIME-Version: 1.0 X-Received: by 10.220.47.10 with SMTP id l10mr153467vcf.32.1380110377287; Wed, 25 Sep 2013 04:59:37 -0700 (PDT) Received: by 10.58.237.230 with HTTP; Wed, 25 Sep 2013 04:59:37 -0700 (PDT) Date: Wed, 25 Sep 2013 07:59:37 -0400 Message-ID: From: Mark Duckworth To: clue@ietf.org Content-Type: multipart/alternative; boundary=001a11c2a58cca07d504e733fc9d X-Mailman-Approved-At: Wed, 25 Sep 2013 05:06:00 -0700 Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 11:59:39 -0000 --001a11c2a58cca07d504e733fc9d Content-Type: text/plain; charset=ISO-8859-1 My emails to this list from my polycom address are not getting through, so I'm trying from a different account. Duplicate messages might show up later. Comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, September 24, 2013 2:45 PM > To: clue@ietf.org > Subject: Re: [clue] Is 2nd most active speaker a role? > > On 9/24/13 11:47 AM, Peter Saint-Andre wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 9/24/13 9:31 AM, Christer Holmberg wrote: > >> Hi, > >> > >> Previously, I gave a comment on the role document, indicating that > >> I would like to have the possibility to indicate things like "2nd > >> most active speaker", "3rd most active speaker" etc. Etc it is a > >> dynamic role, which isn't bound the role of a physical person, but > >> rather to the system. > >> > >> However, when thinking more about it, I am not sure whether it > >> really fits the role concept, or whether it should be something else. > >> > >> Do people have comments on this? > > > > I don't even think most active speaker is a role. IMHO a role is > > something less dynamic (host, scribe, presenter, etc.), whereas "the > > two or three people who are producing the most sound right now" is a > > kind of eventing that doesn't result in changes of roles. > > > > Just my centigram of silver... > > I agree that we don't want roles that change frequently for a given capture. > So attaching this to a capture when speaking, and removing when not is > a really bad idea. [Duckworth, Mark] I agree. > But "most active speaker" and "second most active speaker" *could* be > roles carried by *switched* captures. They would be statically > assigned > - this switched capture always contains the most active speaker. > > I'm undecided whether I like that. It could solve some problems for us. [Duckworth, Mark] I'm undecided also. I can see limited cases where it could be useful. It fits somewhat with "segment switching", as described in the use cases. But not a complete fit, because in that scenario there is a "most active left speaker" and "most active right speaker" etc. And for other scenarios, like the "site switching" case, it would be more like having a set of switched captures in a scene that collectively have a role "most active speaker", but an individual capture would not always be most active speaker. So it quickly gets complicated, and would require more thought to work out how this could be more broadly useful for CLUE. I'll keep it in mind as I think about the switching MCU cases we still need to discuss. > What do others think? > > Thanks, > Paul > > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ --001a11c2a58cca07d504e733fc9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My emails to this list from my polycom address are no= t getting through, so I'm trying from a different account. =A0Duplicate= messages might show up later.

Comments inline.
Mark

> -----Original Message-----
> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf
> Of Paul Kyzivat
> Sent: Tuesday, September 24, 2013 2:45 PM
> To: clue@ietf.org
> Subject: Re: [clue] Is 2nd most active speaker a role?
>
> On 9/24/13 11:47 AM, Peter Saint-Andre wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 9/24/13 9:31 AM, Christer Holmberg wrote:
> >> Hi,
> >>
> >> Previously, I gave a comment on the role document, indicating= that
> >> I would like to have the possibility to indicate things like = "2nd
> >> most active speaker", "3rd most active speaker"= ; etc. Etc it is a
> >> dynamic role, which isn't bound the role of a physical pe= rson, but
> >> rather to the system.
> >>
> >> However, when thinking more about it, I am not sure whether i= t
> >> really fits the role concept, or whether it should be somethi= ng else.
> >>
> >> Do people have comments on this?
> >
> > I don't even think most active speaker is a role. IMHO a role= is
> > something less dynamic (host, scribe, presenter, etc.), whereas &= quot;the
> > two or three people who are producing the most sound right now&qu= ot; is a
> > kind of eventing that doesn't result in changes of roles.
> >
> > Just my centigram of silver...
>
> I agree that we don't want roles that change frequently for a give= n capture.
> So attaching this to a capture when speaking, and removing when not is=
> a really bad idea.

=A0[Duckworth, Mark] I agree.

> But "most active speaker" and "second most active speak= er" *could* be
> roles carried by *switched* captures. They would be statically
> assigned
> - this switched capture always contains the most active speaker.
>
> I'm undecided whether I like that. It could solve some problems fo= r us.

[Duckworth, Mark] I'm undecided also. =A0I can see limited cases where = it could be useful. =A0It fits somewhat with "segment switching",= as described in the use cases. =A0But not a complete fit, because in that = scenario there is a "most active left speaker" and "most act= ive right speaker" etc. =A0And for other scenarios, like the "sit= e switching" case, it would be more like having a set of switched capt= ures in a scene that collectively have a role "most active speaker&quo= t;, but an individual capture would not always be most active speaker. =A0S= o it quickly gets complicated, and would require more thought to work out h= ow this could be more broadly useful for CLUE. =A0I'll keep it in mind = as I think about the switching MCU cases we still need to discuss.

> What do others think?
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> > Peter
> >
> > - --
> > Peter Saint-Andre
> > https://stpeter= .im/
--001a11c2a58cca07d504e733fc9d-- From mrducky@gmail.com Wed Sep 25 05:31:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA6221F94FA for ; Wed, 25 Sep 2013 05:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw0BSER6-5GC for ; Wed, 25 Sep 2013 05:31:31 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD421F9425 for ; Wed, 25 Sep 2013 05:31:30 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id oy12so4526022veb.41 for ; Wed, 25 Sep 2013 05:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=CnDuPmftu7shzMSEejxQHcbGzGExkde6+Y239Ih4OSI=; b=QxuylbajW54w4NW9V2vJryQ4TwlNaimBSD5t4ZYwi0XvhqlCRbusXQNDQKSEicmgaI Rp7ywysaOOl+7TC3sqGnBxBVNFyGqpu8XLjQOPjuHkLiI5fYxBKmz9Mbzso7DZmkQewT PB9psnuc11oj9eml8nIrYgu5jGeorxfvlg5Ai7XNOOIcDFVzycffHHGZ8Hk0cG4jCqzn iQYxBmBtqNkXgn8H/X9VPuyNvSKdF3Xdbj6KlDRthUeOcPHLmB3fkxNQtWmYDl+DuG5f fN8qOEC38GPo75ZKse3u3937HWus6TA3mmOvXBacCzQRmRoRZcv9nle7LPpUEo09umgH 8I9Q== MIME-Version: 1.0 X-Received: by 10.220.46.72 with SMTP id i8mr33329998vcf.10.1380112289957; Wed, 25 Sep 2013 05:31:29 -0700 (PDT) Received: by 10.58.237.230 with HTTP; Wed, 25 Sep 2013 05:31:29 -0700 (PDT) Date: Wed, 25 Sep 2013 08:31:29 -0400 Message-ID: From: Mark Duckworth To: clue@ietf.org Content-Type: multipart/alternative; boundary=001a11c2c674cb102d04e7346e4c Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:31:33 -0000 --001a11c2c674cb102d04e7346e4c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable My emails to this list from my polycom address are not getting through, so I'm trying from a different account. Duplicate messages might show up later. I always thought =93site=94 and =93endpoint=94 are synonymous. I don=92t k= now what the difference would be. I was not using =93site=94 to refer only to multiscreen/multicamera rooms. Mark *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary > Barnes > *Sent:* Tuesday, September 17, 2013 7:21 PM > *To:* Paul Kyzivat > *Cc:* CLUE > *Subject:* Re: [clue] REMINDER!!! WGLC: > draft-ietf-clue-telepresence-requirements-05.txt**** > > ** ** > > On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat > wrote:**** > > Mary,**** > > > > On 9/17/13 5:04 PM, Mary Barnes wrote:**** > > Yes. There are other requirements using the term site. If you look at > the definition of "endpoint", there is the following statement: > Endpoints can be anything from > multiscreen/multicamera rooms to handheld devices. > > So, I think we are using site to refer explicitly/only to > multiscreen/multicamera rooms.**** > > ** ** > > Are we? I think even then we are really talking about endpoints, but with > our design center biased towards multiscreen/multicamera rooms. **** > > > E.g., when we are doing "site switching", a CLUE compatible cell phone is > still going to be treated as a site, together with the telepresence "room= s" > in the session.**** > > [MB] Actually, we don't define "site" in the CLUE framework either (and > the word appears 89 times in the use cases). So, maybe we *should* defi= ne > site and leave most of the requirements alone. I think the word conveys > the concept well and I think we lose something if we change to endpoint i= n > many cases, which we should do consistently if we propose to do so in the > requirements document. [/MB] **** > > > I'm not aware of *anything* that is specific to multiscreen/multicamera > endpoints. **** > > ** ** > > Maybe the easiest thing to do is to just > add a parenthetical comment in that sentence like the following: > > Endpoints can be anything from > multiscreen/multicamera rooms (referred to as "sites") to handheld > devices.**** > > ** ** > > Wouldn't that confuse the definition of site switching? > > Thanks, > Paul**** > > ** ** > > Then, I do think it is appropriate to change the word "site" in REQMT-12 > to "endpoint" as the intent of the requirement should also to endpoints > other than multiscreen/multicamera rooms. I think the use of "site" in > the other requirements is okay.**** > > ** ** > > Mary. > > > On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat > > wrote: > > Mary, > > IIUC, you are proposing to make a change from "site" to "endpoint" > in Reqmnt-12, and otherwise leave things alone? > > Thanks, > Paul > > > On 9/17/13 2:06 PM, Mary Barnes wrote: > > Hi Christian, > > Thanks for taking the time to review this. Comments/responses > below [MB]. > > Mary. > > > On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > **** > > > > >> > > wrote: > > Hello, > > Here are my comments to the WGLC: > > 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST > support a > means to identify > the extent of individual video > captures in > three dimensions. > > Did we decide whether this was with respect to a "plane of > interest" > in 3 dimensions? and/or a volume (i.e. incorporating a > depth aspect) > in 3 dimensions? It probably would be good to clarify this > in the > requirements. > > [MB] I don't know that this particular detail matters in the > requirements document. [/MB] > > > 2) General: At different places there are references to > particular > use cases. However this doesn't appear to used > consistently. e.g. > Regmt-9 regarding interoperability between endpoints using > different > numbers of streams makes references to the heterogeneous > use case. > The heterogeneous use cases mentions different bit rates etc= , > however Reqmts-8, 7 etc don't mention the use case? It > seems to me > that if we include references to use cases that we should > be consistent. > > [MB] Not all requirements can be mapped directly to use cases - > e.g., > 16, 17 & 18. In the cases, where they can, we probably should. Th= e > references are intended to informative. [/MB] > > > 3) REQMT-12: Rather than say "..more than two " > should we use > "..more than two endpoints". We don't have a definition for > "site". > > [MB] We don't have an explicit definition but it can certainly be > derived from the context. We use "site" in several other places > and just > replacing that with endpoint in those cases won't work - e.g,. in > Section 4: "If Alice and Bob are at different sites, Alice needs > to > tell Bob about the camera and sound equipment arrangement at her > site so > that Bob's receiver can create an accurate rendering of her site.= " > That all said, I think we can replace the use of "site" in that > requirement as that's consistent with all the other requirements. > [/MB] > > > 4) General: Do we need to have some text in the document tha= t > indicates that there may be other unspecified requirements > that may > be implemented? The framework has a number of attributes > that aren't > mentioned as part of the requirements e.g. scene > description. Or > alternatively do we capture this by adding a generic > requirement > regarding description of the content of captures/scenes? The > requirements are very focussed on spatial/render aspects > rather than > information pertaining to the selection of captures. > > [MB] I do not believe so. These are the bare bones requirements > - if we > don't have functionality to support these then we haven't done > our job. > However, the solution can certainly define additional > functionality, > that doesn't necessarily map to a specific requirement. The > requirements should not be specifying all the details of the > attributes > necessary to support the use cases - that's the objective of the > framework. Now, if you think there is a general requirement that'= s > missing, certainly you can propose such. Realistically, > requirements > documents are starting points to seed the solution work. Once the > solution is started unless the WG thinks a requirement can't be > met, > it's not necessarily productive to try to make the requirements > document > absolutely complete. Indeed, a number of WGs actually never > publish > requirements documents, but rather just cache them in an > appendix for > historical purposes. [/MB] > > > 5) General: There seems to be a requirement in CLUE of the > ability > to indicate how captures are related to resources. e.g. the > STS > mechanism indicates which captures may be used together (whi= ch > indicates which ones can't be used together) and the CSE > that groups > capture resources. This seems to be an important aspect of > CLUE but > there doesn't appear to be a requirement driving it. > > [MB] As I mentioned previously, we don't need to have a > requirement to > justify every aspect of the solution. We don't want to get > into having > to define capture scene entries, etc. in the requirements. We > don't > need to backwards engineer the requirements to match the > solution. [/MB] > > > Regards, Christian > > > On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* > comments!!! :-( > > I can't advance this document without better indication = of > support from the WG. So I'm extending this WGLC. I'll > be away > next weekend, so I will let this extension run another t= wo > weeks, ending Sunday Sept 29. > > We NEED NEED NEED your comments on this. Please review > it again, > and respond either positively or negatively, whether > you think > it is ready to progress. > > Thanks, > Paul > > On 9/2/13 3:50 PM, Paul Kyzivat wrote: > > With this message I'm announcing the start of WGLC f= or > **** > > draft-ietf-clue-telepresence-____requirements-05**** > > > > > This WGLC will last for roughly two weeks, ending at > midnight GMT on > Sunday September 15. > > It is important to have decisive results from a WGLC= . > (Silence doesn't do it.) > So please, take a last careful look at these > requirements > and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) > > On 8/30/13 6:39 PM, internet-drafts@ietf.org > **** > > > > > wrote: > > > A New Internet-Draft is available from the on-li= ne > Internet-Drafts > directories. > This draft is a work item of the ControLling > mUltiple > streams for > tElepresence Working Group of the IETF. > > Title : Requirements for > Telepresence > Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename :**** > > draft-ietf-clue-telepresence-____requirements-05.txt**** > > > > Pages : 13 > Date : 2013-08-30 > > Abstract: > This memo discusses the requirements for a > specification that enables > telepresence interoperability, by > describing the > relationship between > multiple RTP streams. In addition, the > problem > statement and > definitions are also covered herein. > > > The IETF datatracker status page for this draft > is:**** > > > https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-req= uirements > < > https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-require= ments > >**** > > > > > < > https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-require= ments > < > https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirement= s > >> > > > > There's also a htmlized version available at:***= * > > > http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requireme= nts-05 > < > http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-= 05 > >**** > > > > > < > http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirements-= 05 > < > http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-05>> > > A diff from the previous version is available at= : > **** > > > http://www.ietf.org/rfcdiff?____url2=3Ddraft-ietf-clue-____telepresence-r= equirements-05 > < > http://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requi= rements-05 > >**** > > > > > < > http://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requi= rements-05 > < > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requireme= nts-05 > >> > > > > > Please note that it may take a couple of > minutes from > the time of > submission > until the htmlized version and diff are > available at**** > > tools.ietf.org .**= * > * > > > > > Internet-Drafts are also available by anonymous > FTP at:**** > > ftp://ftp.ietf.org/internet-____drafts/ > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/____listinfo/clue > **** > > > > > > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue > **** > > ** ** > > ** ** > --001a11c2c674cb102d04e7346e4c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
My emails to this list from my polycom address are no= t getting through, so I'm trying from a different account. =A0Duplicate= messages might show up later.

I always thought =93site= =94 and =93endpoint=94 are synonymous. =A0I don=92t know what the differenc= e would be. =A0I was not using =93site=94 to refer only to multiscreen/mult= icamera rooms.

Mark=A0

From: clue-bounc= es@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, September 17, 2013 7:21 PM
To: Paul Kyzivat=
Cc: CLUE
Subject: Re: [clue] REMINDER!!! WGLC: draft-i= etf-clue-telepresence-requirements-05.txt

=A0

On Tue, Se= p 17, 2013 at 5:25 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:<= /p>

Mary,


On 9/17/13 5:04 PM, Mary Barnes wrote:

Yes. =A0There are other requirements using the term site. =A0= If you look at
the definition of "endpoint", there is the foll= owing statement:
Endpoints can be anything from
multiscreen/multicame= ra rooms to handheld devices.

So, I think we are using site to refer explicitly/only to
multiscree= n/multicamera rooms.

=A0

Are we? I think even then we are really talking about end= points, but with our design center biased towards multiscreen/multicamera r= ooms.=A0


E.g., when we are doing "si= te switching", a CLUE compatible cell phone is still going to be treat= ed as a site, together with the telepresence "rooms" in the sessi= on.

[MB] Actually, we don't define "si= te" in the CLUE framework either (and the word appears 89 times in the= use cases). =A0 So, maybe we *should* define site and leave most of the re= quirements alone. =A0I think the word conveys the concept well and I think = we lose something if we change to endpoint in many cases, which we should d= o consistently if we propose to do so in the requirements document. =A0 =A0= [/MB]=A0


I'm not aware of *anything* that is= specific to multiscreen/multicamera endpoints.=A0

=A0

Maybe the easiest thing to do is to just
add a parenthetical comment = in that sentence like the following:

=A0 =A0 =A0 =A0Endpoints can be= anything from
=A0 =A0 =A0 =A0multiscreen/multicamera rooms (referred to as "sites&qu= ot;) to handheld devices.

=A0

Wouldn't that confuse the definitio= n of site switching?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

<= blockquote style=3D"border-style:none none none solid;border-left-color:rgb= (204,204,204);border-left-width:1pt;padding:0in 0in 0in 6pt;margin:5pt 0in = 5pt 4.8pt">

=A0

Then, I do think it is appropriate to ch= ange the word "site" in REQMT-12
to "endpoint" as th= e intent of the requirement should also to endpoints
other than multiscr= een/multicamera rooms. =A0I think the use of "site" in
the other requirements is okay.

=A0

Mary.


On Tue, Sep 17, 2013 at 3:28 PM, Paul K= yzivat <pkyzi= vat@alum.mit.edu

<mailto:<= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank">pkyzivat@alum.mit= .edu>> wrote:

=A0 =A0 Mary,

=A0 =A0 IIUC, you are proposing to make a change f= rom "site" to "endpoint"
=A0 =A0 in Reqmnt-12, and o= therwise leave things alone?

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


=A0 =A0 On 9/17/13 2:06 PM, Mary Barnes wrote:

=A0 =A0 =A0 =A0 H= i Christian,

=A0 =A0 =A0 =A0 Thanks for taking the time to review th= is. Comments/responses
=A0 =A0 =A0 =A0 below [MB].

=A0 =A0 =A0 = =A0 Mary.


=A0 =A0 =A0 =A0 On Mon, Sep 16, 2013 at 11:10 PM, Chri= stian Groves
=A0 =A0 =A0 =A0 <Christian.Groves@nteczone.com
=A0 =A0 =A0 =A0 <mailto= :Christi= an.Groves@nteczone.com>

=A0 =A0 =A0 =A0 <mailto:Christian.Groves@__nteczone.com


=A0 =A0 =A0 =A0 <mailto:Christian.Groves@nteczone.com>>>= ;

=A0 =A0 =A0 =A0 wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0Hello,

= =A0 =A0 =A0 =A0 =A0 =A0 =A0Here are my comments to the WGLC:

=A0 =A0= =A0 =A0 =A0 =A0 =A01) Reqmt-1D - With regards to reqmt-1d: The solution MU= ST
=A0 =A0 =A0 =A0 support a
=A0 =A0 =A0 =A0 =A0 =A0 =A0means to iden= tify
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0the extent of individual video
=A0 =A0 =A0 =A0 captures in
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= three dimensions.

=A0 =A0 =A0 =A0 =A0 =A0 =A0Did we decide whether t= his was with respect to a "plane of
=A0 =A0 =A0 =A0 interest"
=A0 =A0 =A0 =A0 =A0 =A0 =A0in 3 dimension= s? and/or a volume (i.e. incorporating a
=A0 =A0 =A0 =A0 depth aspect)=A0 =A0 =A0 =A0 =A0 =A0 =A0in 3 dimensions? It probably would be good to = clarify this
=A0 =A0 =A0 =A0 in the
=A0 =A0 =A0 =A0 =A0 =A0 =A0requir= ements.

=A0 =A0 =A0 =A0 [MB] I don't know that this particular detail matte= rs in the
=A0 =A0 =A0 =A0 requirements document. =A0[/MB]


=A0= =A0 =A0 =A0 =A0 =A0 =A02) General: At different places there are reference= s to
=A0 =A0 =A0 =A0 particular
=A0 =A0 =A0 =A0 =A0 =A0 =A0use cases. However this doesn't appear to us= ed
=A0 =A0 =A0 =A0 consistently. e.g.
=A0 =A0 =A0 =A0 =A0 =A0 =A0Regm= t-9 regarding interoperability between endpoints using
=A0 =A0 =A0 =A0 d= ifferent
=A0 =A0 =A0 =A0 =A0 =A0 =A0numbers of streams makes references = to the heterogeneous
=A0 =A0 =A0 =A0 use case.
=A0 =A0 =A0 =A0 =A0 =A0 =A0The heterogeneous u= se cases mentions different bit rates etc,
=A0 =A0 =A0 =A0 =A0 =A0 =A0ho= wever Reqmts-8, 7 etc don't mention the use case? It
=A0 =A0 =A0 =A0= seems to me
=A0 =A0 =A0 =A0 =A0 =A0 =A0that if we include references to= use cases that we should
=A0 =A0 =A0 =A0 be consistent.

=A0 =A0 =A0 =A0 [MB] Not all requirem= ents can be mapped directly to use cases -
=A0 =A0 =A0 =A0 e.g.,
=A0 = =A0 =A0 =A0 16, 17 & 18. In the cases, where they can, we probably shou= ld. The
=A0 =A0 =A0 =A0 references are intended to informative. [/MB]

=A0 =A0 =A0 =A0 =A0 =A0 =A03) REQMT-12: Rather than say "..mor= e than two <sites>"
=A0 =A0 =A0 =A0 should we use
=A0 =A0 = =A0 =A0 =A0 =A0 =A0"..more than two endpoints". We don't have= a definition for
=A0 =A0 =A0 =A0 "site".

=A0 =A0 =A0 =A0 [MB] We don't have an explicit definition but it ca= n certainly be
=A0 =A0 =A0 =A0 derived from the context. We use "si= te" in several other places
=A0 =A0 =A0 =A0 and just
=A0 =A0 =A0= =A0 replacing that with endpoint in those cases won't work - e.g,. in<= br> =A0 =A0 =A0 =A0 Section 4: =A0"If Alice and Bob are at different sites= , Alice needs to
=A0 =A0 =A0 =A0 tell Bob about the camera and sound equ= ipment arrangement at her
=A0 =A0 =A0 =A0 site so
=A0 =A0 =A0 =A0 tha= t Bob's receiver can create an accurate rendering of her site." =A0 =A0 =A0 =A0 That all said, I think we can replace the use of "site= " in that
=A0 =A0 =A0 =A0 requirement as that's consistent with= all the other requirements.
=A0 =A0 =A0 =A0 [/MB]


=A0 =A0 = =A0 =A0 =A0 =A0 =A04) General: Do we need to have some text in the document= that
=A0 =A0 =A0 =A0 =A0 =A0 =A0indicates that there may be other unspecified re= quirements
=A0 =A0 =A0 =A0 that may
=A0 =A0 =A0 =A0 =A0 =A0 =A0be imp= lemented? The framework has a number of attributes
=A0 =A0 =A0 =A0 that = aren't
=A0 =A0 =A0 =A0 =A0 =A0 =A0mentioned as part of the requireme= nts e.g. scene
=A0 =A0 =A0 =A0 description. Or
=A0 =A0 =A0 =A0 =A0 =A0 =A0alternatively= do we capture this by adding a generic
=A0 =A0 =A0 =A0 requirement
= =A0 =A0 =A0 =A0 =A0 =A0 =A0regarding description of the content of captures= /scenes? The
=A0 =A0 =A0 =A0 =A0 =A0 =A0requirements are very focussed o= n spatial/render aspects
=A0 =A0 =A0 =A0 rather than
=A0 =A0 =A0 =A0 =A0 =A0 =A0information perta= ining to the selection of captures.

=A0 =A0 =A0 =A0 [MB] I do not be= lieve so. =A0These are the bare bones requirements
=A0 =A0 =A0 =A0 - if = we
=A0 =A0 =A0 =A0 don't have functionality to support these then we= haven't done
=A0 =A0 =A0 =A0 our job.
=A0 =A0 =A0 =A0 =A0 =A0However, the solution ca= n certainly define additional
=A0 =A0 =A0 =A0 functionality,
=A0 =A0 = =A0 =A0 that doesn't necessarily map to a specific requirement. =A0The<= br>=A0 =A0 =A0 =A0 requirements should not be specifying all the details of= the
=A0 =A0 =A0 =A0 attributes
=A0 =A0 =A0 =A0 necessary to support the use = cases - that's the objective of the
=A0 =A0 =A0 =A0 framework. Now, = if you think there is a general requirement that's
=A0 =A0 =A0 =A0 m= issing, certainly you can propose such. Realistically, requirements
=A0 =A0 =A0 =A0 documents are starting points to seed the solution work. On= ce the
=A0 =A0 =A0 =A0 solution is started unless the WG thinks a requir= ement can't be met,
=A0 =A0 =A0 =A0 it's not necessarily product= ive to try to make the requirements
=A0 =A0 =A0 =A0 document
=A0 =A0 =A0 =A0 absolutely complete. =A0Indeed,= a number of WGs actually never publish
=A0 =A0 =A0 =A0 requirements doc= uments, but rather just cache them in an
=A0 =A0 =A0 =A0 appendix for=A0 =A0 =A0 =A0 historical purposes. [/MB]


=A0 =A0 =A0 =A0 =A0 =A0 =A05) General: There seems to be a requirem= ent in CLUE of the
=A0 =A0 =A0 =A0 ability
=A0 =A0 =A0 =A0 =A0 =A0 = =A0to indicate how captures are related to resources. e.g. the STS
=A0 = =A0 =A0 =A0 =A0 =A0 =A0mechanism indicates which captures may be used toget= her (which
=A0 =A0 =A0 =A0 =A0 =A0 =A0indicates which ones can't be used together)= and the CSE
=A0 =A0 =A0 =A0 that groups
=A0 =A0 =A0 =A0 =A0 =A0 =A0c= apture resources. This seems to be an important aspect of
=A0 =A0 =A0 = =A0 CLUE but
=A0 =A0 =A0 =A0 =A0 =A0 =A0there doesn't appear to be a= requirement driving it.

=A0 =A0 =A0 =A0 [MB] As I mentioned previously, we don't need to ha= ve a
=A0 =A0 =A0 =A0 requirement to
=A0 =A0 =A0 =A0 justify every asp= ect of the solution. =A0 We don't want to get
=A0 =A0 =A0 =A0 into h= aving
=A0 =A0 =A0 =A0 to define capture scene entries, etc. in the requi= rements. =A0 We
=A0 =A0 =A0 =A0 don't
=A0 =A0 =A0 =A0 need to backwards engineer the= requirements to match the
=A0 =A0 =A0 =A0 solution. =A0[/MB]

=A0 =A0 =A0 =A0 =A0 =A0 =A0Regards, Christian


=A0 =A0 =A0 =A0 = =A0 =A0 =A0On 16/09/2013 5:32 AM, Paul Kyzivat wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We started WGLC on the requirements = two weeks ago.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It has run for two wee= ks, and there have been *NO*
=A0 =A0 =A0 =A0 comments!!! :-(

=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I can't advance this document without be= tter indication of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0support from the WG. So I'm extendin= g this WGLC. I'll
=A0 =A0 =A0 =A0 be away
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0next weekend, so I will let this extension run another two
= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0weeks, ending Sunday Sept 29.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0We NEED NEED NEED your comments on t= his. Please review
=A0 =A0 =A0 =A0 it again,
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0and respond either positively or negatively, whether
=A0 =A0 = =A0 =A0 you think
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0it is ready to prog= ress.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Paul

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= On 9/2/13 3:50 PM, Paul Kyzivat wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0With this message I'm announcing the start of WGLC for

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-= ietf-clue-telepresence-____requirements-05




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0This WGLC will= last for roughly two weeks, ending at
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0midnight GMT on
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sunday September 15.

=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It is important to have decisive res= ults from a WGLC.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(Silence do= esn't do it.)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So please, = take a last careful look at these
=A0 =A0 =A0 =A0 requirements
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= and comment.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If you like thes= e as they are, please say so.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0Paul (as co-chair)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0On 8/30/13 6:39 PM, internet-drafts@ietf= .org
=A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<mailto:<= a href=3D"mailto:internet-drafts@ietf." target=3D"_blank">internet-drafts@i= etf.__org


=A0 =A0 =A0 =A0 <mailto:internet-drafts@ietf.org>> wrote:


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A New Internet-D= raft is available from the on-line
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0Internet-Drafts
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0directories.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 This draft is a work item of the ControLling
=A0 =A0 =A0 =A0 mUltiple
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0streams for
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tElep= resence Working Group of the IETF.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Requirements for=A0 =A0 =A0 =A0 Telepresence
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Multi-Streams
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 = : Allyn Romanow
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Stephen Botzko
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0Mary Barnes
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Filename =A0 = =A0 =A0 =A0:

=A0 =A0 =A0 =A0 draft-iet= f-clue-telepresence-____requirements-05.txt



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 P= ages =A0 =A0 =A0 =A0 =A0 : 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Date =A0 =A0 = =A0 =A0 =A0 =A0: 2013-08-30

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0Abstract:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 This memo discusses the requirements for a
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0specification that enables
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 telepresence in= teroperability, by
=A0 =A0 =A0 =A0 describing the
=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0relationship between
=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 multiple RTP streams. =A0In additi= on, the
=A0 =A0 =A0 =A0 problem
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0statement and
=A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 definitions are also c= overed herein.


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0The IETF datatracker status page for this draft is:

=A0 =A0 =A0 =A0 https://datatracker.i= etf.org/____doc/draft-ietf-clue-____telepresence-requirements
=A0 = =A0 =A0 =A0 <https://datatracker.ietf.= org/__doc/draft-ietf-clue-__telepresence-requirements>=




=A0 =A0 =A0 =A0 <https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresen= ce-requirements
=A0 =A0 =A0 =A0 <https://datatracker.ietf.= org/doc/draft-ietf-clue-telepresence-requirements>>


=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0There's also a htm= lized version available at:

=A0 =A0 =A0 =A0 http= ://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements-05=
=A0 =A0 =A0 =A0 <http://tools.iet= f.org/html/__draft-ietf-clue-telepresence-__requirements-05><= u>




=A0 =A0 =A0 =A0 <http://tools.ietf.org/html/__draft-ietf-clue-telepresence-__requirem= ents-05
=A0 =A0 =A0 =A0 <http://tools.ietf.org/html/d= raft-ietf-clue-telepresence-requirements-05>>

=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A diff from the previous version is = available at:

=A0 =A0 =A0 =A0 http://www.ietf.org/rfcdiff?____url2=3Ddraft-ietf-clue-____telepresence= -requirements-05
=A0 =A0 =A0 =A0 <http://www.ietf.= org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requirements-05>=




=A0 =A0 =A0 =A0 <http://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__telep= resence-requirements-05
=A0 =A0 =A0 =A0 <http://www.ietf.org/= rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirements-05>>
=



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Please note that it = may take a couple of
=A0 =A0 =A0 =A0 minutes from
=A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0the time of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0submission
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0until the htmlized version and diff are
=A0 =A0 =A0 =A0 available at

=A0 =A0 = =A0 =A0 tools.ietf.org<= /a> <http://tools.ie= tf.org> <http= ://tools.ietf.org>.




=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Internet-Drafts are also available by anonymous
=A0 =A0 =A0 =A0 F= TP at:

=A0 =A0 =A0 =A0 ftp://ftp.ietf.org/i= nternet-____drafts/
=A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-__drafts/>
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<ftp://ftp.ietf.org/internet-__drafts/
=A0 =A0 =A0 =A0 <ftp://ftp.ietf.org/internet-drafts/>>

=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________________= ___________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0c= lue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mail= man/____listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.or= g/mailman/__listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_______________________= ____________________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0= =A0 clue@ietf.org &= lt;mailto:clue@ietf.org<= /a>> <mailto:clue@= ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mail= man/____listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailma= n/__listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>>

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_______________________________= ____________________
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing lis= t
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mail= man/____listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__list= info/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>>

=A0 =A0 =A0 =A0 =A0 =A0 =A0_______________________________________= ____________
=A0 =A0 =A0 =A0 =A0 =A0 =A0clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org> <mailto:clue@ietf.org
=A0 =A0 =A0 =A0 <mailto:clue@ietf.org>>
=A0 =A0 =A0 =A0 https://www.ietf.org/mail= man/____listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/__listinfo/clue>=


=A0 =A0 = =A0 =A0 =A0 =A0 =A0<https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>>



=A0 =A0 =A0 =A0 __________________________________________= _______
=A0 =A0 =A0 =A0 clue mailing list
=A0 =A0 =A0 =A0 clue@iet= f.org <mailto:clu= e@ietf.org>
=A0 =A0 =A0 =A0 https://www.ietf.org/mailman/__listin= fo/clue
=A0 =A0 =A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>

=A0 =A0 _________________________________________________
=A0 =A0 c= lue mailing list
=A0 =A0 clue@ietf.org <mailto:clue@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/clue
=A0 =A0 <https://www.ietf.org/mailman/listinfo/clue>

=A0

=A0

<= /div>
--001a11c2c674cb102d04e7346e4c-- From albrecht.schwarz@alcatel-lucent.com Wed Sep 25 05:54:20 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F2F11E810D for ; Wed, 25 Sep 2013 05:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMOEIJVqfGPf for ; Wed, 25 Sep 2013 05:54:10 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA0211E8109 for ; Wed, 25 Sep 2013 05:54:07 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r8PCs2UG013739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Sep 2013 07:54:04 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r8PCrx1S025266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 14:54:01 +0200 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.70]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 25 Sep 2013 14:54:00 +0200 From: "Schwarz, Albrecht (Albrecht)" To: Mark Duckworth , "clue@ietf.org" Thread-Topic: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt Thread-Index: AQHOuesuZb+d0dxQ10yF7VYc3uUL9pnWZ4Ug Date: Wed, 25 Sep 2013 12:53:59 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC0BEAC7@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_786615F3A85DF44AA2A76164A71FE1AC0BEAC7FR711WXCHMBA03zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 12:54:20 -0000 --_000_786615F3A85DF44AA2A76164A71FE1AC0BEAC7FR711WXCHMBA03zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To "endpoint": I'm pretty convinced that this term originates in ITU-T (before usage in IE= TF), introduced by X.200: Term : (N)-connection-endpoint Definition : A terminator at one end of an (N)-connection within an (N)-ser= vice-access-point. Source : X.200 (94), 5.3.1.3 Thus, "endpoint" is characterized by a) connection concept b) related to a protocol layer and c) offers a service access point. But "site" ... not aware of any definition. From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= k Duckworth Sent: Mittwoch, 25. September 2013 14:31 To: clue@ietf.org Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirem= ents-05.txt My emails to this list from my polycom address are not getting through, so = I'm trying from a different account. Duplicate messages might show up late= r. I always thought "site" and "endpoint" are synonymous. I don't know what t= he difference would be. I was not using "site" to refer only to multiscree= n/multicamera rooms. Mark From: clue-bounces@ietf.org [mailto:clue-boun= ces@ietf.org] On Behalf Of Mary Barnes Sent: Tuesday, September 17, 2013 7:21 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirem= ents-05.txt On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat > wrote: Mary, On 9/17/13 5:04 PM, Mary Barnes wrote: Yes. There are other requirements using the term site. If you look at the definition of "endpoint", there is the following statement: Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. So, I think we are using site to refer explicitly/only to multiscreen/multicamera rooms. Are we? I think even then we are really talking about endpoints, but with o= ur design center biased towards multiscreen/multicamera rooms. E.g., when we are doing "site switching", a CLUE compatible cell phone is s= till going to be treated as a site, together with the telepresence "rooms" = in the session. [MB] Actually, we don't define "site" in the CLUE framework either (and the= word appears 89 times in the use cases). So, maybe we *should* define si= te and leave most of the requirements alone. I think the word conveys the = concept well and I think we lose something if we change to endpoint in many= cases, which we should do consistently if we propose to do so in the requi= rements document. [/MB] I'm not aware of *anything* that is specific to multiscreen/multicamera end= points. Maybe the easiest thing to do is to just add a parenthetical comment in that sentence like the following: Endpoints can be anything from multiscreen/multicamera rooms (referred to as "sites") to handheld d= evices. Wouldn't that confuse the definition of site switching? Thanks, Paul Then, I do think it is appropriate to change the word "site" in REQMT-12 to "endpoint" as the intent of the requirement should also to endpoints other than multiscreen/multicamera rooms. I think the use of "site" in the other requirements is okay. Mary. On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat >> wrote: Mary, IIUC, you are proposing to make a change from "site" to "endpoint" in Reqmnt-12, and otherwise leave things alone? Thanks, Paul On 9/17/13 2:06 PM, Mary Barnes wrote: Hi Christian, Thanks for taking the time to review this. Comments/responses below [MB]. Mary. On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > __nteczone.com >>> wrote: Hello, Here are my comments to the WGLC: 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a means to identify the extent of individual video captures in three dimensions. Did we decide whether this was with respect to a "plane of interest" in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect) in 3 dimensions? It probably would be good to clarify this in the requirements. [MB] I don't know that this particular detail matters in the requirements document. [/MB] 2) General: At different places there are references to particular use cases. However this doesn't appear to used consistently. e.g. Regmt-9 regarding interoperability between endpoints using different numbers of streams makes references to the heterogeneous use case. The heterogeneous use cases mentions different bit rates etc, however Reqmts-8, 7 etc don't mention the use case? It seems to me that if we include references to use cases that we should be consistent. [MB] Not all requirements can be mapped directly to use cases - e.g., 16, 17 & 18. In the cases, where they can, we probably should. The references are intended to informative. [/MB] 3) REQMT-12: Rather than say "..more than two " should we use "..more than two endpoints". We don't have a definition for "site". [MB] We don't have an explicit definition but it can certainly be derived from the context. We use "site" in several other places and just replacing that with endpoint in those cases won't work - e.g,. in Section 4: "If Alice and Bob are at different sites, Alice needs t= o tell Bob about the camera and sound equipment arrangement at her site so that Bob's receiver can create an accurate rendering of her site." That all said, I think we can replace the use of "site" in that requirement as that's consistent with all the other requirements. [/MB] 4) General: Do we need to have some text in the document that indicates that there may be other unspecified requirements that may be implemented? The framework has a number of attributes that aren't mentioned as part of the requirements e.g. scene description. Or alternatively do we capture this by adding a generic requirement regarding description of the content of captures/scenes? The requirements are very focussed on spatial/render aspects rather than information pertaining to the selection of captures. [MB] I do not believe so. These are the bare bones requirements - if we don't have functionality to support these then we haven't done our job. However, the solution can certainly define additional functionality, that doesn't necessarily map to a specific requirement. The requirements should not be specifying all the details of the attributes necessary to support the use cases - that's the objective of the framework. Now, if you think there is a general requirement that's missing, certainly you can propose such. Realistically, requirement= s documents are starting points to seed the solution work. Once the solution is started unless the WG thinks a requirement can't be met= , it's not necessarily productive to try to make the requirements document absolutely complete. Indeed, a number of WGs actually never publis= h requirements documents, but rather just cache them in an appendix for historical purposes. [/MB] 5) General: There seems to be a requirement in CLUE of the ability to indicate how captures are related to resources. e.g. the ST= S mechanism indicates which captures may be used together (which indicates which ones can't be used together) and the CSE that groups capture resources. This seems to be an important aspect of CLUE but there doesn't appear to be a requirement driving it. [MB] As I mentioned previously, we don't need to have a requirement to justify every aspect of the solution. We don't want to get into having to define capture scene entries, etc. in the requirements. We don't need to backwards engineer the requirements to match the solution. [/MB] Regards, Christian On 16/09/2013 5:32 AM, Paul Kyzivat wrote: We started WGLC on the requirements two weeks ago. It has run for two weeks, and there have been *NO* comments!!! :-( I can't advance this document without better indication of support from the WG. So I'm extending this WGLC. I'll be away next weekend, so I will let this extension run another two weeks, ending Sunday Sept 29. We NEED NEED NEED your comments on this. Please review it again, and respond either positively or negatively, whether you think it is ready to progress. Thanks, Paul On 9/2/13 3:50 PM, Paul Kyzivat wrote: With this message I'm announcing the start of WGLC for draft-ietf-clue-telepresence-____requirements-05 This WGLC will last for roughly two weeks, ending at midnight GMT on Sunday September 15. It is important to have decisive results from a WGLC. (Silence doesn't do it.) So please, take a last careful look at these requirements and comment. If you like these as they are, please say so. Thanks, Paul (as co-chair) On 8/30/13 6:39 PM, internet-drafts@ietf.org > __org >>= wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-____requirements-05.txt Pages : 13 Date : 2013-08-30 Abstract: This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. The IETF datatracker status page for this draft is= : https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresen= ce-requirements > There's also a htmlized version available at: http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____req= uirements-05 > A diff from the previous version is available at: http://www.ietf.org/rfcdiff?____url2=3Ddraft-ietf-clue-____telepres= ence-requirements-05 > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-____drafts/ > __________________________________________________= _ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > _________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue _________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue --_000_786615F3A85DF44AA2A76164A71FE1AC0BEAC7FR711WXCHMBA03zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To “endpoint”= :

 <= /p>

I’m pretty convince= d that this term originates in ITU-T (before usage in IETF), introduced by = X.200:

 <= /p>

Term : (N)-connection-endpoint

Definition<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D"> : A terminator at one end of an (N)-connection w= ithin an (N)-service-access-point.

Source : X.200 (94), 5.3.1.3

 <= /p>

Thus, “endpointR= 21; is characterized by

a) connection concept

b) related to a protocol = layer

and

c) offers a service acces= s point.

 <= /p>

But “site” &#= 8230; not aware of any definition.

 <= /p>

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mark Duckworth
Sent: Mittwoch, 25. September 2013 14:31
To: clue@ietf.org
Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-r= equirements-05.txt

 

My emails to this lis= t from my polycom address are not getting through, so I'm trying from a dif= ferent account.  Duplicate messages might show up later.

I always thought “site” and “endpo= int” are synonymous.  I don’t know what the difference wou= ld be.  I was not using “site” to refer only to multiscree= n/multicamera rooms.

Mark 

 

From: clue-bounces@iet= f.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: Tuesday, September 17, 2013 7:21 PM
To: Paul Kyzivat
Cc: CLUE
Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-r= equirements-05.txt

 

On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat= <pkyzivat@al= um.mit.edu> wrote:

Mary,



On 9/17/13 5:04 PM, Mary Barnes wrote:

Yes.  There are other requirements using= the term site.  If you look at
the definition of "endpoint", there is the following statement: Endpoints can be anything from
multiscreen/multicamera rooms to handheld devices.

So, I think we are using site to refer explicitly/only to
multiscreen/multicamera rooms.

 

Are we? I think even then we are really talki= ng about endpoints, but with our design center biased towards multiscreen/m= ulticamera rooms. 


E.g., when we are doing "site switching", a CLUE compatible cell = phone is still going to be treated as a site, together with the telepresenc= e "rooms" in the session.

[MB] Actually, we don't define "site&quo= t; in the CLUE framework either (and the word appears 89 times in the use c= ases).   So, maybe we *should* define site and leave most of the requirements alone.  I think the word conveys the concept= well and I think we lose something if we change to endpoint in many cases,= which we should do consistently if we propose to do so in the requirements= document.    [/MB] 


I'm not aware of *anything* that is specific to multiscreen/multicamera end= points. 

 

Maybe the easiest thing to do is to just
add a parenthetical comment in that sentence like the following:

       Endpoints can be anything from
       multiscreen/multicamera rooms (referred to as &q= uot;sites") to handheld devices.

 

Wouldn't that confuse the definition of site = switching?

        Thanks,
        Paul

 

Then, I do think it is appropriate to change = the word "site" in REQMT-12
to "endpoint" as the intent of the requirement should also to end= points
other than multiscreen/multicamera rooms.  I think the use of "si= te" in
the other requirements is okay.

 

Mary.


On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu

<mailto:pkyzivat@alum.mit.edu>> wrote:

    Mary,

    IIUC, you are proposing to make a change from "site"= ; to "endpoint"
    in Reqmnt-12, and otherwise leave things alone?

             Thanks,
             Paul


    On 9/17/13 2:06 PM, Mary Barnes wrote:

        Hi Christian,

        Thanks for taking the time to review this. Comm= ents/responses
        below [MB].

        Mary.


        On Mon, Sep 16, 2013 at 11:10 PM, Christian Gro= ves
        <Christian.Groves@nteczone.com
        <mailto:Christian.Groves@nteczone.com>

        <mailto:Christian.Groves@__nteczone.com<= /span>


        <mailto:Christian.Groves@nteczone.com>>>= ;

        wrote:

             Hello,

             Here are my comments to the= WGLC:

             1) Reqmt-1D - With regards = to reqmt-1d: The solution MUST
        support a
             means to identify
                     = ;                  the extent = of individual video
        captures in
                     = ;                  three dimen= sions.

             Did we decide whether this = was with respect to a "plane of
        interest"
             in 3 dimensions? and/or a v= olume (i.e. incorporating a
        depth aspect)
             in 3 dimensions? It probabl= y would be good to clarify this
        in the
             requirements.

        [MB] I don't know that this particular detail m= atters in the
        requirements document.  [/MB]


             2) General: At different pl= aces there are references to
        particular
             use cases. However this doe= sn't appear to used
        consistently. e.g.
             Regmt-9 regarding interoper= ability between endpoints using
        different
             numbers of streams makes re= ferences to the heterogeneous
        use case.
             The heterogeneous use cases= mentions different bit rates etc,
             however Reqmts-8, 7 etc don= 't mention the use case? It
        seems to me
             that if we include referenc= es to use cases that we should
        be consistent.

        [MB] Not all requirements can be mapped directl= y to use cases -
        e.g.,
        16, 17 & 18. In the cases, where they can, = we probably should. The
        references are intended to informative. [/MB]

             3) REQMT-12: Rather than sa= y "..more than two <sites>"
        should we use
             "..more than two endpo= ints". We don't have a definition for
        "site".

        [MB] We don't have an explicit definition but i= t can certainly be
        derived from the context. We use "site&quo= t; in several other places
        and just
        replacing that with endpoint in those cases won= 't work - e.g,. in
        Section 4:  "If Alice and Bob are at = different sites, Alice needs to
        tell Bob about the camera and sound equipment a= rrangement at her
        site so
        that Bob's receiver can create an accurate rend= ering of her site."
        That all said, I think we can replace the use o= f "site" in that
        requirement as that's consistent with all the o= ther requirements.
        [/MB]


             4) General: Do we need to h= ave some text in the document that
             indicates that there may be= other unspecified requirements
        that may
             be implemented? The framewo= rk has a number of attributes
        that aren't
             mentioned as part of the re= quirements e.g. scene
        description. Or
             alternatively do we capture= this by adding a generic
        requirement
             regarding description of th= e content of captures/scenes? The
             requirements are very focus= sed on spatial/render aspects
        rather than
             information pertaining to t= he selection of captures.

        [MB] I do not believe so.  These are the b= are bones requirements
        - if we
        don't have functionality to support these then = we haven't done
        our job.
           However, the solution can certainl= y define additional
        functionality,
        that doesn't necessarily map to a specific requ= irement.  The
        requirements should not be specifying all the d= etails of the
        attributes
        necessary to support the use cases - that's the= objective of the
        framework. Now, if you think there is a general= requirement that's
        missing, certainly you can propose such. Realis= tically, requirements
        documents are starting points to seed the solut= ion work. Once the
        solution is started unless the WG thinks a requ= irement can't be met,
        it's not necessarily productive to try to make = the requirements
        document
        absolutely complete.  Indeed, a number of = WGs actually never publish
        requirements documents, but rather just cache t= hem in an
        appendix for
        historical purposes. [/MB]


             5) General: There seems to = be a requirement in CLUE of the
        ability
             to indicate how captures ar= e related to resources. e.g. the STS
             mechanism indicates which c= aptures may be used together (which
             indicates which ones can't = be used together) and the CSE
        that groups
             capture resources. This see= ms to be an important aspect of
        CLUE but
             there doesn't appear to be = a requirement driving it.

        [MB] As I mentioned previously, we don't need t= o have a
        requirement to
        justify every aspect of the solution.   We= don't want to get
        into having
        to define capture scene entries, etc. in the re= quirements.   We
        don't
        need to backwards engineer the requirements to = match the
        solution.  [/MB]


             Regards, Christian


             On 16/09/2013 5:32 AM, Paul= Kyzivat wrote:

                 We started WG= LC on the requirements two weeks ago.
                 It has run fo= r two weeks, and there have been *NO*
        comments!!! :-(

                 I can't advan= ce this document without better indication of
                 support from = the WG. So I'm extending this WGLC. I'll
        be away
                 next weekend,= so I will let this extension run another two
                 weeks, ending= Sunday Sept 29.

                 We NEED NEED = NEED your comments on this. Please review
        it again,
                 and respond e= ither positively or negatively, whether
        you think
                 it is ready t= o progress.

                     = ; Thanks,
                     = ; Paul

                 On 9/2/13 3:5= 0 PM, Paul Kyzivat wrote:

                     = ;With this message I'm announcing the start of WGLC for

            &nb= sp;        draft-ietf-clue-telepresence-____requirement= s-05




                     = ;This WGLC will last for roughly two weeks, ending at
                     = ;midnight GMT on
                     = ;Sunday September 15.

                     = ;It is important to have decisive results from a WGLC.
                     = ;(Silence doesn't do it.)
                     = ;So please, take a last careful look at these
        requirements
                     = ;and comment.
                     = ;If you like these as they are, please say so.

                     = ;      Thanks,
                     = ;      Paul (as co-chair)

                     = ;On 8/30/13 6:39 PM, internet-drafts@ietf.org
        <mailto:internet-drafts@ietf.org>

            &nb= sp;        <mailto:internet-drafts@ietf.__org<= /p>


        <mailto:internet-drafts@ietf.org>> wrote:


                     = ;    A New Internet-Draft is available from the on-line
                     = ;    Internet-Drafts
                     = ;    directories.
                     = ;       This draft is a work item of the ControLling
        mUltiple
                     = ;    streams for
                     = ;    tElepresence Working Group of the IETF.

                     = ;         Title           : Re= quirements for
        Telepresence
                     = ;    Multi-Streams
                     = ;         Author(s)       : Allyn Romano= w
                     = ;                     &nb= sp;          Stephen Botzko
                     = ;                     &nb= sp;          Mary Barnes
                     = ;         Filename        :

        draft-ietf-clue-t= elepresence-____requirements-05.txt



                     = ;         Pages           : 13=
                     = ;         Date            = ;: 2013-08-30

                     = ;    Abstract:
                     = ;         This memo discusses the requirements for a                      = ;    specification that enables
                     = ;         telepresence interoperability, by
        describing the
                     = ;    relationship between
                     = ;         multiple RTP streams.  In addition, the<= br>         problem
                     = ;    statement and
                     = ;         definitions are also covered herein.


                     = ;    The IETF datatracker status page for this draft is:

        https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requi= rements
        <https://d= atatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements&g= t;




        <https://d= atatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements         <https://datat= racker.ietf.org/doc/draft-ietf-clue-telepresence-requirements>>


                     = ;    There's also a htmlized version available at:

        http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirement= s-05
        <http://tools= .ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05>




        <http://tools= .ietf.org/html/__draft-ietf-clue-telepresence-__requirements-05
        <http://tools.iet= f.org/html/draft-ietf-clue-telepresence-requirements-05>>

                     = ;    A diff from the previous version is available at:=

        http://www.ietf.org/rfcdiff?____url2=3Ddraft-ietf-clue-____telepresence-req= uirements-05
        <http= ://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requirement= s-05>




        <http= ://www.ietf.org/rfcdiff?__url2=3Ddraft-ietf-clue-__telepresence-requirement= s-05
        <http://w= ww.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirements-05= >>




                     = ;    Please note that it may take a couple of
        minutes from
                     = ;    the time of
                     = ;    submission
                     = ;    until the htmlized version and diff are
        available at

        tools.ietf.org <= http://tools.ietf.org> <http://tools= .ietf.org>.




                     = ;    Internet-Drafts are also available by anonymous
        FTP at:

        ftp:/= /ftp.ietf.org/internet-____drafts/
        <ftp://ftp.ietf.org/internet-__drafts/>
                     = ;    <ftp://ftp.ietf.org/internet-__drafts/
        <ftp://ftp.ietf.org/internet-drafts/>>

                     = ;    ___________________________________________________
                     = ;    clue mailing list
        clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org
        <mailto:clue@ietf.org>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clu= e>
                     = ;    <https://www.ietf.org/mailman/__listinfo/clue
        <https://www.ietf.org/mailman/listinfo/clue>>


                     = ;___________________________________________________
                     = ;clue mailing list
        clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org
        <mailto:clue@ietf.org>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clu= e>
                     = ;<https://www.ietf.org/mailman/__listinfo/clue
        <https://www.ietf.org/mailman/listinfo/clue>>


                 _____________= ______________________________________
                 clue mailing = list
        clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org
        <mailto:clue@ietf.org>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clu= e>
                 <https:/= /www.ietf.org/mailman/__listinfo/clue
        <https://www.ietf.org/mailman/listinfo/clue>>


             ___________________________= ________________________
             clue mailing list
        clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org
        <mailto:clue@ietf.org>>
        https://www.ietf.org/mailman/____listinfo/clue
        <https://www.ietf.org/mailman/__listinfo/clu= e>

 

 

 

--_000_786615F3A85DF44AA2A76164A71FE1AC0BEAC7FR711WXCHMBA03zeu_-- From mrducky@gmail.com Wed Sep 25 06:27:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A1221F9E33 for ; Wed, 25 Sep 2013 06:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qmc2MtrndlqJ for ; Wed, 25 Sep 2013 06:27:26 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2FD21F9E96 for ; Wed, 25 Sep 2013 06:27:20 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id eh20so4821240lab.5 for ; Wed, 25 Sep 2013 06:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qDn4ihC5dM0YpBg1zA4E7fopr+yYuCwxHyn73K6hiMI=; b=cTT1S3W+rGIRDR2GlMayFFZDDSrbJhStTUdohnOHVu1s2tq2ufbjKnE4eOV9yXpFny JF0uEePhhoPzePiO/hsMhiIAlfKn30yQKpHExq+v28Nkt/xehp+Xa0i3RNnIv9U80Lmw as2RPl7N8HnLHj68v/tPK8xoFhIcGpczwxode0HwcAxxQSCYRP+/mZv6ZhBQT/WjKJ9+ 7/4A1TR5ekB2sN3uOVMq7ZSQBK+O76YhCXf+ZAlWQyEM584BV7W4o7Gs8JavzoPvL2kK iOFy0T8dLPgHe5vyHBxaeGAe3yv37pBJziYxsc4sfyFrgg+GnFsw/IT8P5LKQShRr3Mz M3Ug== MIME-Version: 1.0 X-Received: by 10.152.170.233 with SMTP id ap9mr91597lac.51.1380115639409; Wed, 25 Sep 2013 06:27:19 -0700 (PDT) Received: by 10.114.27.129 with HTTP; Wed, 25 Sep 2013 06:27:19 -0700 (PDT) Date: Wed, 25 Sep 2013 09:27:19 -0400 Message-ID: From: Mark Duckworth To: clue@ietf.org Content-Type: multipart/alternative; boundary=089e011760876fa12404e73536c4 Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 13:27:27 -0000 --089e011760876fa12404e73536c4 Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, I think the requirements document is ready to progress. Mark -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Sunday, September 15, 2013 3:32 PM To: clue@ietf.org Subject: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt We started WGLC on the requirements two weeks ago. It has run for two weeks, and there have been *NO* comments!!! :-( I can't advance this document without better indication of support from the WG. So I'm extending this WGLC. I'll be away next weekend, so I will let this extension run another two weeks, ending Sunday Sept 29. We NEED NEED NEED your comments on this. Please review it again, and respond either positively or negatively, whether you think it is ready to progress. Thanks, Paul On 9/2/13 3:50 PM, Paul Kyzivat wrote: > With this message I'm announcing the start of WGLC for > draft-ietf-clue-telepresence-requirements-05 > > This WGLC will last for roughly two weeks, ending at midnight GMT on > Sunday September 15. > > It is important to have decisive results from a WGLC. > (Silence doesn't do it.) > So please, take a last careful look at these requirements and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) --089e011760876fa12404e73536c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Paul,

I think the requirements document is ready to progress.

Mark

-----Original Message-----
From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of Paul Kyzivat
Sent: Sunday, September 15, 2013 3:32 PM
To: clue@ietf.org
Subject: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements= -05.txt

We started WGLC on the requirements two weeks ago.
It has run for two weeks, and there have been *NO* comments!!! :-(

I can't advance this document without better indication of support from= the WG. So I'm extending this WGLC. I'll be away next weekend, so = I will let this extension run another two weeks, ending Sunday Sept 29.

We NEED NEED NEED your comments on this. Please review it again, and respon= d either positively or negatively, whether you think it is ready to progres= s.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

On 9/2/13 3:50 PM, Paul Kyzivat wrote:
> With this message I'm announcing the start of WGLC for
> draft-ietf-clue-telepresence-requirements-05
>
> This WGLC will last for roughly two weeks, ending at midnight GMT on > Sunday September 15.
>
> It is important to have decisive results from a WGLC.
> (Silence doesn't do it.)
> So please, take a last careful look at these requirements and comment.=
> If you like these as they are, please say so.
>
> =A0 =A0 =A0Thanks,
> =A0 =A0 =A0Paul (as co-chair)
--089e011760876fa12404e73536c4-- From Christian.Groves@nteczone.com Wed Sep 25 06:39:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E74821F9F03 for ; Wed, 25 Sep 2013 06:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TszzGE4etUv6 for ; Wed, 25 Sep 2013 06:39:27 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 1227421F9F50 for ; Wed, 25 Sep 2013 06:39:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAArnQlJ20ZLF/2dsb2JhbAANRgiDP4N7vRqBNIMZAQEBAwEBAQEgFRsVBgsQCxgCAgUhAgIPAhYwBg0BBQIBAYd8EqhpdZI1BIEpjGuBPQeCaIE1A5QflzqBUA Received: from ppp118-209-146-197.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.146.197]) by ipmail06.adl6.internode.on.net with ESMTP; 25 Sep 2013 23:09:23 +0930 Message-ID: <5242E785.60103@nteczone.com> Date: Wed, 25 Sep 2013 23:39:17 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> <5241DBC4.9000506@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4AB73E@ESESSMB209.ericsson.se> <5242C0FA.1010209@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ABC04@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4ABC04@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 13:39:28 -0000 Hello Christer, Please see below. Christian On 25/09/2013 9:46 PM, Christer Holmberg wrote: > Hi, > >>>> In CLUE we have been talking about two modes: "legacy mode" and "CLUE mode". >>>> >>>> IMO (and Mary's) we need a new name to replace "legacy" mode. >>>> "Legacy" has the wrong connotation - of just old stuff that we are >>>> trying to get away from. That isn't what we mean here. Rather we mean something like "non-clue mode", but that it too cumbersome. I could live with "clueless mode", though it sounds a bit like a joke. >>> Another term that have been used is "single-stream mode". Not sure >>> that is very good either, though, because in the example I intend to >>> present next week there are actually 4 streams in the non-clue mode :) >> [CNG] In Q.5/16 in the requirements document we have a legacy use case as well as requirements for interworking to legacy devices. I think the term is fine. We could always add a definition somewhere if its unclear. > Does Q.5/16 have a definition that we could use? [CNG] Here's the description of the legacy use case from F.TPS-Req: This use case describes a case where a legacy videoconferencing endpoint (or other heterogeneous device such as voice only endpoint) is involved in the telepresence session. The legacy endpoint does not understand additions related to telepresence functionality and interworking is required to communicate between the telepresence and legacy endpoints. Figure 8 illustrates the use case. This use case may also utilise other legacy equipment such as a legacy H.323 MCU in order to participate in a conference. > > >>>>> Without going into the details in this thread, "legacy mode" >>>>> basically means communication between a CLUE entity and a non-CLUE entity (read: >>>>> an entity that does not support the CLUE protocol). >>>>> >>>>> In "CLUE mode", there is a data channel established for the exchange >>>>> of CLUE protocol messages. >>>>> >>>>> One of the question has been whether a loss of that data channel >>>>> means an automatic fallback to "legacy mode", or whether a fallback >>>>> requires an explicit Offer, where the data channel is disabled etc. >>>>> >>>>> My opinion is that fallback to legacy DOES require an explicit >>>>> Offer, e.g. for the following reasons: >>>>> >>>>> 1) Make sure that all parties are aware of the fallback. >>>>> >>>>> 2) There might be dedicated m=audio/video lines for legacy mode, and >>>>> during clue mode they might be disabled. An Offer is needed in order >>>>> to enable them. >>>>> >>>>> 3) Similar to 2), there are a number of dedicated m=audio/video >>>>> lines for clue mode, and when there is a fallback to legacy mode >>>>> they need to be disabled (keeping them enabled might keep unecessary >>>>> resources locked, and may also affect charging, etc). >>>> I agree with all the above. >>>> >>>> It has been proposed by some that it might be desirable to close the clue channel yet remain in CLUE mode. >>>> >>>> At least in principle this could work. The last negotiated >>>> advertisement and configuration would remain in effect. I guess this would save *some* (small) amount of resources in cases where no changes in clue configuration are anticipated. >>>> >>>> If we did support this, then we would require an even more overt way to indicate the transition to legacy mode. >>>> >>>> Personally I don't find this compelling. I'm satisfied with absence or explicit closing of the clue channel as the indicator for legacy mode. >>>> But I think we need to get consensus on this. >>> There may be a number of reason (some of which end users don't have any control over) why a the clue channel goes down, so my opinion is still that explicit closing (read: SDP Offer) is needed. >>> >>> Having said that, if the clue channel does go down, we probably need some text on how to re-establish it. >> [CNG] I think Paul is referring to me when he says "some". This was in the context of what does it actually mean to the media if the >> CLUE data channel is closed? If the CLUE data channel is closed it doesn't automatically mean that the media is removed or that the encoding >> of the media changes. The media is only removed or changed via SDP. So you can remove the CLUE data channel but the media established as a >> result of a CLUE exchange remains. What do we assume about the metadata (i.e. CLUE attributes) regarding those streams? i.e. is the spatial >> information valid or no longer valid, etc? > My idea is that, in legacy mode, we only have a single audio stream, two video streams (of which one is for presentation/screen sharing), so there is no need for spatial information. > > If you want to exchange spatial information - you use CLUE. [CNG] I agree that if you want spatial information you use CLUE. I think there's a difference in thinking of what legacy means. You seem to assign a particular mode or configuration of streams. For me legacy is with respect of the absence of CLUE rather than a particular media configuration. An endpoint could have 5 video streams and still be legacy if it doesn't understand CLUE. > > >> Does the removal or the CLUE data channel only give a legacy state? or is the legacy mode reverting back to media that would have been established in the absence of CLUE support? > In my opinion, there is no "that would have been established". In the reverting-back-to-legacy SDP Offer, you need to explicitly negotiate the media you are going to use, the same way you do when you send the initial Offer for the session. [CNG] Your definition of legacy above would fit my "that would have been established" description. If the endpoint didn't have CLUE it would have only used one audio and two video streams in the initial offer. > > Regards, > > Christer > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Wed Sep 25 06:42:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 400AD1F0D36 for ; Wed, 25 Sep 2013 06:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiCx1MtMETLP for ; Wed, 25 Sep 2013 06:42:30 -0700 (PDT) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8441F0D37 for ; Wed, 25 Sep 2013 06:42:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsBAArnQlJ20ZLF/2dsb2JhbAANRAqDP0zASYE0gxkBAQEEAQEBLwEFGxsEBhELEQQBAQEJDAoIBwkDAgECARUfCQgTBgIBAQUSh3IFqGmTLo4OgUoGBIQTA5NehU2Tfg Received: from ppp118-209-146-197.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.146.197]) by ipmail06.adl6.internode.on.net with ESMTP; 25 Sep 2013 23:12:27 +0930 Message-ID: <5242E83B.2000403@nteczone.com> Date: Wed, 25 Sep 2013 23:42:19 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 13:42:32 -0000 Hello Mark, A site could be thought of as a building. I.e. the Polycom site in Andover has several telepresence endpoints. Regards, Christian On 25/09/2013 10:31 PM, Mark Duckworth wrote: > My emails to this list from my polycom address are not getting > through, so I'm trying from a different account. Duplicate messages > might show up later. > > I always thought “site” and “endpoint” are synonymous. I don’t know > what the difference would be. I was not using “site” to refer only to > multiscreen/multicamera rooms. > > Mark > > *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] *On > Behalf Of *Mary Barnes > *Sent:* Tuesday, September 17, 2013 7:21 PM > *To:* Paul Kyzivat > *Cc:* CLUE > *Subject:* Re: [clue] REMINDER!!! WGLC: > draft-ietf-clue-telepresence-requirements-05.txt > > On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat > > wrote: > > Mary, > > > > On 9/17/13 5:04 PM, Mary Barnes wrote: > > Yes. There are other requirements using the term site. If you > look at > the definition of "endpoint", there is the following statement: > Endpoints can be anything from > multiscreen/multicamera rooms to handheld devices. > > So, I think we are using site to refer explicitly/only to > multiscreen/multicamera rooms. > > Are we? I think even then we are really talking about > endpoints, but with our design center biased towards > multiscreen/multicamera rooms. > > > E.g., when we are doing "site switching", a CLUE compatible > cell phone is still going to be treated as a site, together > with the telepresence "rooms" in the session. > > [MB] Actually, we don't define "site" in the CLUE framework either > (and the word appears 89 times in the use cases). So, maybe we > *should* define site and leave most of the requirements alone. I > think the word conveys the concept well and I think we lose > something if we change to endpoint in many cases, which we should > do consistently if we propose to do so in the requirements > document. [/MB] > > > I'm not aware of *anything* that is specific to > multiscreen/multicamera endpoints. > > Maybe the easiest thing to do is to just > add a parenthetical comment in that sentence like the > following: > > Endpoints can be anything from > multiscreen/multicamera rooms (referred to as "sites") to > handheld devices. > > Wouldn't that confuse the definition of site switching? > > Thanks, > Paul > > Then, I do think it is appropriate to change the word > "site" in REQMT-12 > to "endpoint" as the intent of the requirement should also > to endpoints > other than multiscreen/multicamera rooms. I think the use > of "site" in > the other requirements is okay. > > Mary. > > > On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat > > > >> wrote: > > Mary, > > IIUC, you are proposing to make a change from "site" to > "endpoint" > in Reqmnt-12, and otherwise leave things alone? > > Thanks, > Paul > > > On 9/17/13 2:06 PM, Mary Barnes wrote: > > Hi Christian, > > Thanks for taking the time to review this. Comments/responses > below [MB]. > > Mary. > > > On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > > > > > __nteczone.com > > > >>> > > wrote: > > Hello, > > Here are my comments to the WGLC: > > 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST > support a > means to identify > the extent of individual video > captures in > three dimensions. > > Did we decide whether this was with respect to a "plane of > interest" > in 3 dimensions? and/or a volume (i.e. incorporating a > depth aspect) > in 3 dimensions? It probably would be good to clarify this > in the > requirements. > > [MB] I don't know that this particular detail matters in the > requirements document. [/MB] > > > 2) General: At different places there are references to > particular > use cases. However this doesn't appear to used > consistently. e.g. > Regmt-9 regarding interoperability between endpoints using > different > numbers of streams makes references to the heterogeneous > use case. > The heterogeneous use cases mentions different bit rates etc, > however Reqmts-8, 7 etc don't mention the use case? It > seems to me > that if we include references to use cases that we should > be consistent. > > [MB] Not all requirements can be mapped directly to use > cases - > e.g., > 16, 17 & 18. In the cases, where they can, we probably > should. The > references are intended to informative. [/MB] > > > 3) REQMT-12: Rather than say "..more than two " > should we use > "..more than two endpoints". We don't have a definition for > "site". > > [MB] We don't have an explicit definition but it can > certainly be > derived from the context. We use "site" in several other > places > and just > replacing that with endpoint in those cases won't work - > e.g,. in > Section 4: "If Alice and Bob are at different sites, Alice > needs to > tell Bob about the camera and sound equipment arrangement > at her > site so > that Bob's receiver can create an accurate rendering of > her site." > That all said, I think we can replace the use of "site" in > that > requirement as that's consistent with all the other > requirements. > [/MB] > > > 4) General: Do we need to have some text in the document that > indicates that there may be other unspecified requirements > that may > be implemented? The framework has a number of attributes > that aren't > mentioned as part of the requirements e.g. scene > description. Or > alternatively do we capture this by adding a generic > requirement > regarding description of the content of captures/scenes? The > requirements are very focussed on spatial/render aspects > rather than > information pertaining to the selection of captures. > > [MB] I do not believe so. These are the bare bones > requirements > - if we > don't have functionality to support these then we haven't done > our job. > However, the solution can certainly define additional > functionality, > that doesn't necessarily map to a specific requirement. The > requirements should not be specifying all the details of the > attributes > necessary to support the use cases - that's the objective > of the > framework. Now, if you think there is a general > requirement that's > missing, certainly you can propose such. Realistically, > requirements > documents are starting points to seed the solution work. > Once the > solution is started unless the WG thinks a requirement > can't be met, > it's not necessarily productive to try to make the > requirements > document > absolutely complete. Indeed, a number of WGs actually > never publish > requirements documents, but rather just cache them in an > appendix for > historical purposes. [/MB] > > > 5) General: There seems to be a requirement in CLUE of the > ability > to indicate how captures are related to resources. e.g. > the STS > mechanism indicates which captures may be used together (which > indicates which ones can't be used together) and the CSE > that groups > capture resources. This seems to be an important aspect of > CLUE but > there doesn't appear to be a requirement driving it. > > [MB] As I mentioned previously, we don't need to have a > requirement to > justify every aspect of the solution. We don't want to get > into having > to define capture scene entries, etc. in the requirements. We > don't > need to backwards engineer the requirements to match the > solution. [/MB] > > > Regards, Christian > > > On 16/09/2013 5:32 AM, Paul Kyzivat wrote: > > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* > comments!!! :-( > > I can't advance this document without better indication of > support from the WG. So I'm extending this WGLC. I'll > be away > next weekend, so I will let this extension run another two > weeks, ending Sunday Sept 29. > > We NEED NEED NEED your comments on this. Please review > it again, > and respond either positively or negatively, whether > you think > it is ready to progress. > > Thanks, > Paul > > On 9/2/13 3:50 PM, Paul Kyzivat wrote: > > With this message I'm announcing the start of WGLC for > > draft-ietf-clue-telepresence-____requirements-05 > > > > > This WGLC will last for roughly two weeks, ending at > midnight GMT on > Sunday September 15. > > It is important to have decisive results from a WGLC. > (Silence doesn't do it.) > So please, take a last careful look at these > requirements > and comment. > If you like these as they are, please say so. > > Thanks, > Paul (as co-chair) > > On 8/30/13 6:39 PM, internet-drafts@ietf.org > > > > > __org > > > >> wrote: > > > A New Internet-Draft is available from the on-line > Internet-Drafts > directories. > This draft is a work item of the ControLling > mUltiple > streams for > tElepresence Working Group of the IETF. > > Title : Requirements for > Telepresence > Multi-Streams > Author(s) : Allyn Romanow > Stephen Botzko > Mary Barnes > Filename : > > draft-ietf-clue-telepresence-____requirements-05.txt > > > > Pages : 13 > Date : 2013-08-30 > > Abstract: > This memo discusses the requirements for a > specification that enables > telepresence interoperability, by > describing the > relationship between > multiple RTP streams. In addition, the > problem > statement and > definitions are also covered herein. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-requirements > > > > > > > > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____requirements-05 > > > > > > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?____url2=draft-ietf-clue-____telepresence-requirements-05 > > > > > > > > > > > > Please note that it may take a couple of > minutes from > the time of > submission > until the htmlized version and diff are > available at > > tools.ietf.org > . > > > > > Internet-Drafts are also available by anonymous > FTP at: > > ftp://ftp.ietf.org/internet-____drafts/ > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > ___________________________________________________ > clue mailing list > clue@ietf.org > > >> > https://www.ietf.org/mailman/____listinfo/clue > > > > > > > > > > _________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > > > _________________________________________________ > clue mailing list > clue@ietf.org > > https://www.ietf.org/mailman/__listinfo/clue > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Thu Sep 26 00:04:21 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5198C11E815F for ; Thu, 26 Sep 2013 00:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz+KXZgzn7bY for ; Thu, 26 Sep 2013 00:04:17 -0700 (PDT) Received: from slohubcasprd01.polycom.com (pslo1s08.emea.polycom.com [140.242.27.25]) by ietfa.amsl.com (Postfix) with ESMTP id 558F811E8160 for ; Thu, 26 Sep 2013 00:04:11 -0700 (PDT) Received: from Crpehubprd01.polycom.com (10.236.0.158) by slohubcasprd01.polycom.com (172.27.1.145) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 25 Sep 2013 22:11:42 +0100 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 24 Sep 2013 15:09:31 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Tue, 24 Sep 2013 15:09:29 -0700 Thread-Topic: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt Thread-Index: Ac6ySlCnlM5Cbzx4SUSGBzwY35qr6wHKFkMw Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333D6F8@CRPMBOXPRD07.polycom.com> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> In-Reply-To: <52360B40.9030702@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 07:04:21 -0000 Hi Paul, I think the requirements document is ready to progress. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Sunday, September 15, 2013 3:32 PM > To: clue@ietf.org > Subject: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence- > requirements-05.txt >=20 > We started WGLC on the requirements two weeks ago. > It has run for two weeks, and there have been *NO* comments!!! :-( >=20 > I can't advance this document without better indication of support from t= he > WG. So I'm extending this WGLC. I'll be away next weekend, so I will let = this > extension run another two weeks, ending Sunday Sept 29. >=20 > We NEED NEED NEED your comments on this. Please review it again, and > respond either positively or negatively, whether you think it is ready to > progress. >=20 > Thanks, > Paul >=20 > On 9/2/13 3:50 PM, Paul Kyzivat wrote: > > With this message I'm announcing the start of WGLC for > > draft-ietf-clue-telepresence-requirements-05 > > > > This WGLC will last for roughly two weeks, ending at midnight GMT on > > Sunday September 15. > > > > It is important to have decisive results from a WGLC. > > (Silence doesn't do it.) > > So please, take a last careful look at these requirements and comment. > > If you like these as they are, please say so. > > > > Thanks, > > Paul (as co-chair) > > > > On 8/30/13 6:39 PM, internet-drafts@ietf.org wrote: > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the ControLling mUltiple streams for > >> tElepresence Working Group of the IETF. > >> > >> Title : Requirements for Telepresence Multi-Streams > >> Author(s) : Allyn Romanow > >> Stephen Botzko > >> Mary Barnes > >> Filename : draft-ietf-clue-telepresence-requirements-05.txt > >> Pages : 13 > >> Date : 2013-08-30 > >> > >> Abstract: > >> This memo discusses the requirements for a specification that enab= les > >> telepresence interoperability, by describing the relationship betw= een > >> multiple RTP streams. In addition, the problem statement and > >> definitions are also covered herein. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-require > >> ments > >> > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements- > >> 05 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requir= e > >> ments-05 > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission until the htmlized version and diff are available at > >> tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Thu Sep 26 00:04:23 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353A111E816F for ; Thu, 26 Sep 2013 00:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A5voVb-nVK1 for ; Thu, 26 Sep 2013 00:04:19 -0700 (PDT) Received: from slohubcasprd02.polycom.com (pslo1s08.emea.polycom.com [140.242.27.25]) by ietfa.amsl.com (Postfix) with ESMTP id 57AEF11E8167 for ; Thu, 26 Sep 2013 00:04:11 -0700 (PDT) Received: from crpehubprd02.polycom.com (10.236.0.154) by slohubcasprd02.polycom.com (172.27.1.146) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 25 Sep 2013 22:12:14 +0100 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 25 Sep 2013 04:01:55 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 25 Sep 2013 04:01:50 -0700 Thread-Topic: [clue] Is 2nd most active speaker a role? Thread-Index: Ac65VnJAxj1FtLvnRIOI17IO8HbR/wACUidgAB+2VqA= Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333D7E0@CRPMBOXPRD07.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> <5241B412.6050507@stpeter.im> <5241DDC7.5020608@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] FW: Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 07:04:23 -0000 Comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: Tuesday, September 24, 2013 2:45 PM > To: clue@ietf.org > Subject: Re: [clue] Is 2nd most active speaker a role? >=20 > On 9/24/13 11:47 AM, Peter Saint-Andre wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 9/24/13 9:31 AM, Christer Holmberg wrote: > >> Hi, > >> > >> Previously, I gave a comment on the role document, indicating that=20 > >> I would like to have the possibility to indicate things like "2nd=20 > >> most active speaker", "3rd most active speaker" etc. Etc it is a=20 > >> dynamic role, which isn't bound the role of a physical person, but=20 > >> rather to the system. > >> > >> However, when thinking more about it, I am not sure whether it=20 > >> really fits the role concept, or whether it should be something else. > >> > >> Do people have comments on this? > > > > I don't even think most active speaker is a role. IMHO a role is=20 > > something less dynamic (host, scribe, presenter, etc.), whereas "the=20 > > two or three people who are producing the most sound right now" is a=20 > > kind of eventing that doesn't result in changes of roles. > > > > Just my centigram of silver... >=20 > I agree that we don't want roles that change frequently for a given captu= re. > So attaching this to a capture when speaking, and removing when not is=20 > a really bad idea. [Duckworth, Mark] I agree. > But "most active speaker" and "second most active speaker" *could* be=20 > roles carried by *switched* captures. They would be statically=20 > assigned > - this switched capture always contains the most active speaker. >=20 > I'm undecided whether I like that. It could solve some problems for us. [Duckworth, Mark] I'm undecided also. I can see limited cases where it cou= ld be useful. It fits somewhat with "segment switching", as described in t= he use cases. But not a complete fit, because in that scenario there is a = "most active left speaker" and "most active right speaker" etc. And for ot= her scenarios, like the "site switching" case, it would be more like having= a set of switched captures in a scene that collectively have a role "most = active speaker", but an individual capture would not always be most active = speaker. So it quickly gets complicated, and would require more thought to= work out how this could be more broadly useful for CLUE. I'll keep it in = mind as I think about the switching MCU cases we still need to discuss. > What do others think? >=20 > Thanks, > Paul >=20 > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > > Comment: GPGTools - http://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > > iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I > +4A > > > qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzw > QYXl6 > > > /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6G > wHe > > > MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb > > > AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4x > oV38y > > > nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEax > YQTXc1h > > RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H > > > Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF > 7R > > > ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm > > > TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6v > U > > > 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9E > K > > bkuiL3QvoacUrL+QXIeW > > =3DFRgG > > -----END PGP SIGNATURE----- > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Thu Sep 26 00:04:27 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAA11E8175 for ; Thu, 26 Sep 2013 00:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2dm6bdEOZ3E for ; Thu, 26 Sep 2013 00:04:23 -0700 (PDT) Received: from slohubcasprd02.polycom.com (pslo1s08.emea.polycom.com [140.242.27.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0156011E816B for ; Thu, 26 Sep 2013 00:04:13 -0700 (PDT) Received: from crpehubprd02.polycom.com (10.236.0.154) by slohubcasprd02.polycom.com (172.27.1.146) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 25 Sep 2013 22:12:15 +0100 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Tue, 24 Sep 2013 13:02:42 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 24 Sep 2013 13:02:40 -0700 Thread-Topic: [clue] Is 2nd most active speaker a role? Thread-Index: Ac65VnJAxj1FtLvnRIOI17IO8HbR/wACUidg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333D629@CRPMBOXPRD07.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> <5241B412.6050507@stpeter.im> <5241DDC7.5020608@alum.mit.edu> In-Reply-To: <5241DDC7.5020608@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 07:04:27 -0000 Comments inline. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Tuesday, September 24, 2013 2:45 PM > To: clue@ietf.org > Subject: Re: [clue] Is 2nd most active speaker a role? >=20 > On 9/24/13 11:47 AM, Peter Saint-Andre wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 9/24/13 9:31 AM, Christer Holmberg wrote: > >> Hi, > >> > >> Previously, I gave a comment on the role document, indicating that I > >> would like to have the possibility to indicate things like "2nd most > >> active speaker", "3rd most active speaker" etc. Etc it is a dynamic > >> role, which isn't bound the role of a physical person, but rather to > >> the system. > >> > >> However, when thinking more about it, I am not sure whether it really > >> fits the role concept, or whether it should be something else. > >> > >> Do people have comments on this? > > > > I don't even think most active speaker is a role. IMHO a role is > > something less dynamic (host, scribe, presenter, etc.), whereas "the > > two or three people who are producing the most sound right now" is a > > kind of eventing that doesn't result in changes of roles. > > > > Just my centigram of silver... >=20 > I agree that we don't want roles that change frequently for a given captu= re. > So attaching this to a capture when speaking, and removing when not is a > really bad idea. [Duckworth, Mark] I agree. > But "most active speaker" and "second most active speaker" *could* be > roles carried by *switched* captures. They would be statically assigned > - this switched capture always contains the most active speaker. >=20 > I'm undecided whether I like that. It could solve some problems for us. [Duckworth, Mark] I'm undecided also. I can see limited cases where it cou= ld be useful. It fits somewhat with "segment switching", as described in t= he use cases. But not a complete fit, because in that scenario there is a = "most active left speaker" and "most active right speaker" etc. And for ot= her scenarios, like the "site switching" case, it would be more like having= a set of switched captures in a scene that collectively have a role "most = active speaker", but an individual capture would not always be most active = speaker. So it quickly gets complicated, and would require more thought to= work out how this could be more broadly useful for CLUE. I'll keep it in = mind as I think about the switching MCU cases we still need to discuss. > What do others think? >=20 > Thanks, > Paul >=20 > > Peter > > > > - -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > > Comment: GPGTools - http://gpgtools.org > > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > > > > iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I > +4A > > > qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzw > QYXl6 > > > /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6G > wHe > > > MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb > > > AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4x > oV38y > > > nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEax > YQTXc1h > > RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H > > > Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF > 7R > > > ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm > > > TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6v > U > > > 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9E > K > > bkuiL3QvoacUrL+QXIeW > > =3DFRgG > > -----END PGP SIGNATURE----- > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Thu Sep 26 00:04:28 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF1311E8178 for ; Thu, 26 Sep 2013 00:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnyStJ-jpkp3 for ; Thu, 26 Sep 2013 00:04:21 -0700 (PDT) Received: from slohubcasprd01.polycom.com (pslo1s08.emea.polycom.com [140.242.27.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADCD11E8169 for ; Thu, 26 Sep 2013 00:04:12 -0700 (PDT) Received: from Crpehubprd01.polycom.com (10.236.0.158) by slohubcasprd01.polycom.com (172.27.1.145) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 25 Sep 2013 22:11:42 +0100 Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Tue, 24 Sep 2013 13:46:41 -0700 From: "Duckworth, Mark" To: Mary Barnes , Paul Kyzivat Date: Tue, 24 Sep 2013 13:46:39 -0700 Thread-Topic: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt Thread-Index: Ac6z/J/JXBl4dHXMRNeUBbefQ0mUYQFakz4Q Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333D68B@CRPMBOXPRD07.polycom.com> References: <20130830223924.16258.71205.idtracker@ietfa.amsl.com> <5224EC1A.1020603@alum.mit.edu> <52360B40.9030702@alum.mit.edu> <5237D653.901@nteczone.com> <5238BB74.6090907@alum.mit.edu> <5238D6CA.3080500@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D60333D68BCRPMBOXPRD07pol_" MIME-Version: 1.0 Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirements-05.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2013 07:04:28 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60333D68BCRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I always thought "site" and "endpoint" are synonymous. I don't know what t= he difference would be. I was not using "site" to refer only to multiscree= n/multicamera rooms. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mar= y Barnes Sent: Tuesday, September 17, 2013 7:21 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] REMINDER!!! WGLC: draft-ietf-clue-telepresence-requirem= ents-05.txt On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat > wrote: Mary, On 9/17/13 5:04 PM, Mary Barnes wrote: Yes. There are other requirements using the term site. If you look at the definition of "endpoint", there is the following statement: Endpoints can be anything from multiscreen/multicamera rooms to handheld devices. So, I think we are using site to refer explicitly/only to multiscreen/multicamera rooms. Are we? I think even then we are really talking about endpoints, but with o= ur design center biased towards multiscreen/multicamera rooms. E.g., when we are doing "site switching", a CLUE compatible cell phone is s= till going to be treated as a site, together with the telepresence "rooms" = in the session. [MB] Actually, we don't define "site" in the CLUE framework either (and the= word appears 89 times in the use cases). So, maybe we *should* define si= te and leave most of the requirements alone. I think the word conveys the = concept well and I think we lose something if we change to endpoint in many= cases, which we should do consistently if we propose to do so in the requi= rements document. [/MB] I'm not aware of *anything* that is specific to multiscreen/multicamera end= points. Maybe the easiest thing to do is to just add a parenthetical comment in that sentence like the following: Endpoints can be anything from multiscreen/multicamera rooms (referred to as "sites") to handheld d= evices. Wouldn't that confuse the definition of site switching? Thanks, Paul Then, I do think it is appropriate to change the word "site" in REQMT-12 to "endpoint" as the intent of the requirement should also to endpoints other than multiscreen/multicamera rooms. I think the use of "site" in the other requirements is okay. Mary. On Tue, Sep 17, 2013 at 3:28 PM, Paul Kyzivat >> wrote: Mary, IIUC, you are proposing to make a change from "site" to "endpoint" in Reqmnt-12, and otherwise leave things alone? Thanks, Paul On 9/17/13 2:06 PM, Mary Barnes wrote: Hi Christian, Thanks for taking the time to review this. Comments/responses below [MB]. Mary. On Mon, Sep 16, 2013 at 11:10 PM, Christian Groves > __nteczone.com >>> wrote: Hello, Here are my comments to the WGLC: 1) Reqmt-1D - With regards to reqmt-1d: The solution MUST support a means to identify the extent of individual video captures in three dimensions. Did we decide whether this was with respect to a "plane of interest" in 3 dimensions? and/or a volume (i.e. incorporating a depth aspect) in 3 dimensions? It probably would be good to clarify this in the requirements. [MB] I don't know that this particular detail matters in the requirements document. [/MB] 2) General: At different places there are references to particular use cases. However this doesn't appear to used consistently. e.g. Regmt-9 regarding interoperability between endpoints using different numbers of streams makes references to the heterogeneous use case. The heterogeneous use cases mentions different bit rates etc, however Reqmts-8, 7 etc don't mention the use case? It seems to me that if we include references to use cases that we should be consistent. [MB] Not all requirements can be mapped directly to use cases - e.g., 16, 17 & 18. In the cases, where they can, we probably should. The references are intended to informative. [/MB] 3) REQMT-12: Rather than say "..more than two " should we use "..more than two endpoints". We don't have a definition for "site". [MB] We don't have an explicit definition but it can certainly be derived from the context. We use "site" in several other places and just replacing that with endpoint in those cases won't work - e.g,. in Section 4: "If Alice and Bob are at different sites, Alice needs t= o tell Bob about the camera and sound equipment arrangement at her site so that Bob's receiver can create an accurate rendering of her site." That all said, I think we can replace the use of "site" in that requirement as that's consistent with all the other requirements. [/MB] 4) General: Do we need to have some text in the document that indicates that there may be other unspecified requirements that may be implemented? The framework has a number of attributes that aren't mentioned as part of the requirements e.g. scene description. Or alternatively do we capture this by adding a generic requirement regarding description of the content of captures/scenes? The requirements are very focussed on spatial/render aspects rather than information pertaining to the selection of captures. [MB] I do not believe so. These are the bare bones requirements - if we don't have functionality to support these then we haven't done our job. However, the solution can certainly define additional functionality, that doesn't necessarily map to a specific requirement. The requirements should not be specifying all the details of the attributes necessary to support the use cases - that's the objective of the framework. Now, if you think there is a general requirement that's missing, certainly you can propose such. Realistically, requirement= s documents are starting points to seed the solution work. Once the solution is started unless the WG thinks a requirement can't be met= , it's not necessarily productive to try to make the requirements document absolutely complete. Indeed, a number of WGs actually never publis= h requirements documents, but rather just cache them in an appendix for historical purposes. [/MB] 5) General: There seems to be a requirement in CLUE of the ability to indicate how captures are related to resources. e.g. the ST= S mechanism indicates which captures may be used together (which indicates which ones can't be used together) and the CSE that groups capture resources. This seems to be an important aspect of CLUE but there doesn't appear to be a requirement driving it. [MB] As I mentioned previously, we don't need to have a requirement to justify every aspect of the solution. We don't want to get into having to define capture scene entries, etc. in the requirements. We don't need to backwards engineer the requirements to match the solution. [/MB] Regards, Christian On 16/09/2013 5:32 AM, Paul Kyzivat wrote: We started WGLC on the requirements two weeks ago. It has run for two weeks, and there have been *NO* comments!!! :-( I can't advance this document without better indication of support from the WG. So I'm extending this WGLC. I'll be away next weekend, so I will let this extension run another two weeks, ending Sunday Sept 29. We NEED NEED NEED your comments on this. Please review it again, and respond either positively or negatively, whether you think it is ready to progress. Thanks, Paul On 9/2/13 3:50 PM, Paul Kyzivat wrote: With this message I'm announcing the start of WGLC for draft-ietf-clue-telepresence-____requirements-05 This WGLC will last for roughly two weeks, ending at midnight GMT on Sunday September 15. It is important to have decisive results from a WGLC. (Silence doesn't do it.) So please, take a last careful look at these requirements and comment. If you like these as they are, please say so. Thanks, Paul (as co-chair) On 8/30/13 6:39 PM, internet-drafts@ietf.org > __org >>= wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Mary Barnes Filename : draft-ietf-clue-telepresence-____requirements-05.txt Pages : 13 Date : 2013-08-30 Abstract: This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. The IETF datatracker status page for this draft is= : https://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresen= ce-requirements > There's also a htmlized version available at: http://tools.ietf.org/html/____draft-ietf-clue-telepresence-____req= uirements-05 > A diff from the previous version is available at: http://www.ietf.org/rfcdiff?____url2=3Ddraft-ietf-clue-____telepres= ence-requirements-05 > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-____drafts/ > __________________________________________________= _ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > ___________________________________________________ clue mailing list clue@ietf.org > >> https://www.ietf.org/mailman/____listinfo/clue > _________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue _________________________________________________ clue mailing list clue@ietf.org > https://www.ietf.org/mailman/__listinfo/clue --_000_49E45C59CA48264997FEBFB29B6BC2D60333D68BCRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I always = thought “site” and “endpoint” are synonymous. = I don’t know what the difference would be.  I was not using = 220;site” to refer only to multiscreen/multicamera rooms.<= /span>

 

Mark

<= o:p> 

From: cl= ue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary= Barnes
Sent: Tuesday, September 17, 2013 7:21 PM
To: P= aul Kyzivat
Cc: CLUE
Subject: Re: [clue] REMINDER!!! WG= LC: draft-ietf-clue-telepresence-requirements-05.txt

<= /div>

 

On Tue, Sep 17, 2013 at 5:25 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wr= ote:

Mary,


On 9/17/13 5:04 PM, Mary Barnes wrote:

= Yes.  There are other requirements using the term site.  If you l= ook at
the definition of "endpoint", there is the following st= atement:
Endpoints can be anything from
multiscreen/multicamera rooms= to handheld devices.

So, I think we are using site to refer explici= tly/only to
multiscreen/multicamera rooms.

 

Are we? I think even = then we are really talking about endpoints, but with our design center bias= ed towards multiscreen/multicamera rooms. 

=

E.g., when we are doing "site switching", a CLUE compatible cel= l phone is still going to be treated as a site, together with the teleprese= nce "rooms" in the session.

[MB] Actually, we don't define "site" in the CLUE= framework either (and the word appears 89 times in the use cases).   = So, maybe we *should* define site and leave most of the requirements alone.=  I think the word conveys the concept well and I think we lose someth= ing if we change to endpoint in many cases, which we should do consistently= if we propose to do so in the requirements document.    [/MB]&nb= sp;


I'm not aware of *anything* that is specific to m= ultiscreen/multicamera endpoints. 

 

Maybe the easiest thing to do = is to just
add a parenthetical comment in that sentence like the followi= ng:

       Endpoints can be anything from
&nb= sp;      multiscreen/multicamera rooms (referred to as "= ;sites") to handheld devices.

 

Wouldn't that confu= se the definition of site switching?

        Tha= nks,
        Paul

 

Then, I do think it= is appropriate to change the word "site" in REQMT-12
to "= ;endpoint" as the intent of the requirement should also to endpointsother than multiscreen/multicamera rooms.  I think the use of "= site" in
the other requirements is okay.

 

Mary.


On Tue= , Sep 17, 2013 at 3:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu

<= div>

<mailto:pkyzivat@alum.mit.edu>> wrote:

  =   Mary,

    IIUC, you are proposing to make a change = from "site" to "endpoint"
    in Reqmnt-12= , and otherwise leave things alone?

        &nbs= p;    Thanks,
             = Paul


    On 9/17/13 2:06 PM, Mary Barnes wrote:
        Hi Christian,

      &nbs= p; Thanks for taking the time to review this. Comments/responses
  =       below [MB].

        Mary.

        On Mon, Sep 16, 2013 at 11:10 PM, Chr= istian Groves
        <Christian.Groves@nteczone.com<= br>        <mailto:Christian.Groves@nteczone.com>

        <mailt= o:Christian.Groves@<= /a>__nteczone.com


        &= lt;mailto:Christian.Groves@nteczone.com>>>

     =   wrote:

             Hello= ,

             Here are my commen= ts to the WGLC:

             1) R= eqmt-1D - With regards to reqmt-1d: The solution MUST
    &nbs= p;   support a
             mean= s to identify
                &n= bsp;                     =  the extent of individual video
        capture= s in
                  &nbs= p;                    thr= ee dimensions.

             Did w= e decide whether this was with respect to a "plane of
   =     interest"
            =  in 3 dimensions? and/or a volume (i.e. incorporating a
  &nbs= p;     depth aspect)
           =  in 3 dimensions? It probably would be good to clarify this
 =       in the
            &= nbsp;requirements.

        [MB] I don't know tha= t this particular detail matters in the
        requ= irements document.  [/MB]


         = ;    2) General: At different places there are references to
&= nbsp;       particular
         =    use cases. However this doesn't appear to used
  &nbs= p;     consistently. e.g.
          &= nbsp;  Regmt-9 regarding interoperability between endpoints using
&= nbsp;       different
          =    numbers of streams makes references to the heterogeneous
&n= bsp;       use case.
          &= nbsp;  The heterogeneous use cases mentions different bit rates etc,             however Reqmts-8, 7 etc d= on't mention the use case? It
        seems to me             that if we include referen= ces to use cases that we should
        be consisten= t.

        [MB] Not all requirements can be mapp= ed directly to use cases -
        e.g.,
  &= nbsp;     16, 17 & 18. In the cases, where they can, we proba= bly should. The
        references are intended to i= nformative. [/MB]


            &nbs= p;3) REQMT-12: Rather than say "..more than two <sites>"        should we use
        &= nbsp;    "..more than two endpoints". We don't have a d= efinition for
        "site".

 = ;       [MB] We don't have an explicit definition but it can= certainly be
        derived from the context. We u= se "site" in several other places
        = and just
        replacing that with endpoint in tho= se cases won't work - e.g,. in
        Section 4: &n= bsp;"If Alice and Bob are at different sites, Alice needs to
 =       tell Bob about the camera and sound equipment arrange= ment at her
        site so
      =   that Bob's receiver can create an accurate rendering of her site.&qu= ot;
        That all said, I think we can replace th= e use of "site" in that
        requiremen= t as that's consistent with all the other requirements.
    &n= bsp;   [/MB]


            &nbs= p;4) General: Do we need to have some text in the document that
  &= nbsp;          indicates that there may be other u= nspecified requirements
        that may
  &= nbsp;          be implemented? The framework has a= number of attributes
        that aren't
  =            mentioned as part of the requireme= nts e.g. scene
        description. Or
  &nb= sp;          alternatively do we capture this by a= dding a generic
        requirement
   =          regarding description of the content of = captures/scenes? The
             req= uirements are very focussed on spatial/render aspects
    &nbs= p;   rather than
             in= formation pertaining to the selection of captures.

    &nb= sp;   [MB] I do not believe so.  These are the bare bones require= ments
        - if we
       = don't have functionality to support these then we haven't done
  &= nbsp;     our job.
           Ho= wever, the solution can certainly define additional
     =   functionality,
        that doesn't necessar= ily map to a specific requirement.  The
       = requirements should not be specifying all the details of the
  &nb= sp;     attributes
        necessary to su= pport the use cases - that's the objective of the
      &= nbsp; framework. Now, if you think there is a general requirement that's        missing, certainly you can propose such. Reali= stically, requirements
        documents are startin= g points to seed the solution work. Once the
       = solution is started unless the WG thinks a requirement can't be met,
&n= bsp;       it's not necessarily productive to try to make th= e requirements
        document
    &nb= sp;   absolutely complete.  Indeed, a number of WGs actually neve= r publish
        requirements documents, but rather= just cache them in an
        appendix for
 = ;       historical purposes. [/MB]


    =          5) General: There seems to be a requireme= nt in CLUE of the
        ability
    &= nbsp;        to indicate how captures are related to re= sources. e.g. the STS
             me= chanism indicates which captures may be used together (which
  &nbs= p;          indicates which ones can't be used tog= ether) and the CSE
        that groups
  &nb= sp;          capture resources. This seems to be a= n important aspect of
        CLUE but
  &nb= sp;          there doesn't appear to be a requirem= ent driving it.

        [MB] As I mentioned prev= iously, we don't need to have a
        requirement = to
        justify every aspect of the solution. &nb= sp; We don't want to get
        into having
&nbs= p;       to define capture scene entries, etc. in the requir= ements.   We
        don't
    &nb= sp;   need to backwards engineer the requirements to match the
&nbs= p;       solution.  [/MB]


    &nbs= p;        Regards, Christian


    &= nbsp;        On 16/09/2013 5:32 AM, Paul Kyzivat wrote:=

                 We st= arted WGLC on the requirements two weeks ago.
       = ;          It has run for two weeks, and there hav= e been *NO*
        comments!!! :-(

  &n= bsp;              I can't advance this d= ocument without better indication of
          =        support from the WG. So I'm extending this WGLC.= I'll
        be away
       =          next weekend, so I will let this extensi= on run another two
              &nbs= p;  weeks, ending Sunday Sept 29.

        &= nbsp;        We NEED NEED NEED your comments on this. P= lease review
        it again,
    &nbs= p;            and respond either positively o= r negatively, whether
        you think
  &n= bsp;              it is ready to progres= s.

                  &n= bsp;   Thanks,
              &nb= sp;       Paul

          &nb= sp;      On 9/2/13 3:50 PM, Paul Kyzivat wrote:

 = ;                    With= this message I'm announcing the start of WGLC for

              &nb= sp;      draft-ietf-clue-telepresence-____requirements-05




      &nbs= p;              This WGLC will last for = roughly two weeks, ending at
            &= nbsp;        midnight GMT on
      &n= bsp;              Sunday September 15.
                   =  It is important to have decisive results from a WGLC.
  &nbs= p;                  (Silence d= oesn't do it.)
                &= nbsp;    So please, take a last careful look at these
  &= nbsp;     requirements
          &nbs= p;          and comment.
      &= nbsp;              If you like these as = they are, please say so.

            &= nbsp;              Thanks,
  &nb= sp;                     &= nbsp;  Paul (as co-chair)

          &n= bsp;          On 8/30/13 6:39 PM, internet-drafts@ietf.org<= br>        <mailto:internet-drafts@ietf.org>

             = ;        <mailto:internet-drafts@ietf.__org

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>
     =   <mailto:internet-drafts@ietf.org>> wrote:


    =                      = ;A New Internet-Draft is available from the on-line
     =                    Inter= net-Drafts
                 = ;        directories.
        &n= bsp;                   This dr= aft is a work item of the ControLling
        mUltip= le
                   =      streams for
          &nbs= p;              tElepresence Working Gro= up of the IETF.

              &nb= sp;               Title     &n= bsp;     : Requirements for
        Telepr= esence
                  &n= bsp;      Multi-Streams
         = ;                     Aut= hor(s)       : Allyn Romanow
        =                      = ;                     &nb= sp;  Stephen Botzko
             = ;                     &nb= sp;                  Mary Barn= es
                   =           Filename        :

        draft-i= etf-clue-telepresence-____requirements-05.txt



               = ;               Pages     &nbs= p;     : 13
              &= nbsp;               Date     &= nbsp;      : 2013-08-30

        &= nbsp;                Abstract:
&= nbsp;                    =         This memo discusses the requirements for a
=                      = ;    specification that enables
        &n= bsp;                     = telepresence interoperability, by
        describing= the
                  &nbs= p;      relationship between
        =                      = ; multiple RTP streams.  In addition, the
      &nbs= p; problem
                 = ;        statement and
        &= nbsp;                    = definitions are also covered herein.


       = ;                  The IETF da= tatracker status page for this draft is:

        ht= tps://datatracker.ietf.org/____doc/draft-ietf-clue-____telepresence-require= ments
        <https://datatracker.ietf.org/__doc/draft-ietf-clue-__telepresence-requi= rements>




  =       <https://datatrac= ker.ietf.org/__doc/draft-ietf-clue-__telepresence-requirements
 = ;       <https://datatracke= r.ietf.org/doc/draft-ietf-clue-telepresence-requirements>>


                  &nb= sp;      There's also a htmlized version available at:<= /o:p>

        http://tools.ietf.org/html/____draft-ietf-clue-tele= presence-____requirements-05
        <http://tools.ietf.org/html/__draft-ietf-clue-telepr= esence-__requirements-05>

        http://www.ietf.org/rfcdiff?____url2=3Ddra= ft-ietf-clue-____telepresence-requirements-05
      &= nbsp; <http://www.ietf.org/rfcdif= f?__url2=3Ddraft-ietf-clue-__telepresence-requirements-05>




        <= http://www.ietf.org/rfcdiff?__url2= =3Ddraft-ietf-clue-__telepresence-requirements-05
    &nbs= p;   <http://www.ietf.org/rfcdif= f?url2=3Ddraft-ietf-clue-telepresence-requirements-05>>



                  &n= bsp;      Please note that it may take a couple of
 =       minutes from
          &n= bsp;              the time of
  =                      = ;  submission
              &nbs= p;          until the htmlized version and diff ar= e
        available at

        tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>.

<= div>




          &nb= sp;              Internet-Drafts are als= o available by anonymous
        FTP at:<= /p>

        ftp://ftp.ietf.org/int= ernet-____drafts/
        <ftp://ftp.ietf.org/intern= et-__drafts/>
              &n= bsp;          <ftp://ftp.ietf.org/internet-__drafts/
        <ftp://ftp.ietf.org/internet-drafts/>>= ;

                  &nb= sp;      ___________________________________________________=
                    &= nbsp;    clue mailing list
        clue@ietf.org <mailto:clue@ietf.org> <= mailto:clue@ietf.org=
        <mailto:clue@ietf.org>>
       = https://www.ietf.org/mailman/____listinfo/clue
    &nbs= p;   <https://www.ietf.org/mailman/__listinfo/clue>
 = ;                     &nb= sp;  <https://www.ietf.org/mailman/__listinfo/clue
  &n= bsp;     <https://www.ietf.org/mailman/listinfo/clue>>=


                  =    ___________________________________________________
  =                    clue m= ailing list
        clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org
      =   <mailto:clue@i= etf.org>>
        https://www.ietf.org/m= ailman/____listinfo/clue
        <https://www= .ietf.org/mailman/__listinfo/clue>
        &n= bsp;            <https://www.ietf.org/mail= man/__listinfo/clue
        <https://www.ietf.o= rg/mailman/listinfo/clue>>


       =          ________________________________________= ___________
                &nbs= p;clue mailing list
        clue@ietf.org <mailto:clue@ietf.org> <mailto:clue@ietf.org
   =     <mailto:clue@ietf.org>>
        https://www.ie= tf.org/mailman/____listinfo/clue
        <htt= ps://www.ietf.org/mailman/__listinfo/clue>
      &= nbsp;          <https://www.ietf.org/mailman/__= listinfo/clue
        <https://www.ietf.org/mai= lman/listinfo/clue>>


         = ;    ___________________________________________________
 = ;            clue mailing list
  &nbs= p;     clue@ie= tf.org <mailto:cl= ue@ietf.org> <mailto:clue@ietf.org
        <mailto:clue@ietf.org>>
&n= bsp;       https://www.ietf.org/mailman/____listinfo/clue<= /a>
        <https://www.ietf.org/mailman/__listi= nfo/clue>


             <https:= //www.ietf.org/mailman/__listinfo/clue
        &= lt;https://www.ietf.org/mailman/listinfo/clue>>




=         _______________________________________________= __
        clue mailing list
     =   clue@ietf.org <mailto:clue@ietf.o= rg>
        https://www.ietf.org/mailman/__li= stinfo/clue
        <https://www.ietf.org/mailm= an/listinfo/clue>


    _________________________= ________________________
    clue mailing list
   = ; clue@ietf.org <= mailto:clue@ietf.org= >
    https://www.ietf.org/mailman/__listinfo/clue
&= nbsp;   <https://www.ietf.org/mailman/listinfo/clue>

 

<= /blockquote>

 

= --_000_49E45C59CA48264997FEBFB29B6BC2D60333D68BCRPMBOXPRD07pol_-- From christer.holmberg@ericsson.com Thu Sep 26 03:02:05 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6140921F964C for ; Thu, 26 Sep 2013 03:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.693 X-Spam-Level: X-Spam-Status: No, score=-5.693 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03TuaA0ETMuG for ; Thu, 26 Sep 2013 03:01:56 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 19CAF21E809A for ; Thu, 26 Sep 2013 03:01:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-6b-524405ea26a7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 37.EA.16099.AE504425; Thu, 26 Sep 2013 12:01:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0328.009; Thu, 26 Sep 2013 12:01:14 +0200 From: Christer Holmberg To: "clue@ietf.org" Thread-Topic: VC mandatory in MCC? Thread-Index: Ac66nT3QD6vyNumySIurmb3ukrTbMQ== Date: Thu, 26 Sep 2013 10:01:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AC7E6@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AC7E6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvre4rVpcgg23fxSz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujCmn/rIWHBOvuLqhlbWB8aZIFyMnh4SAicSK3atYIWwxiQv3 1rN1MXJxCAkcZpR4sKOfFcJZwijxbv1kIIeDg03AQqL7nzZIg4iAssTRzf1sILawgKzE8z8X GCHiShJd51+xQNh6Egv2PAJbwCKgKtFw5QoziM0r4Csx9fFmsHpGoMXfT61hArGZBcQlbj2Z zwRxkIDEkj3nmSFsUYmXj/9BHaoosfNsOzNEfb5Ez8/H7BAzBSVOznzCMoFRaBaSUbOQlM1C UgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMbLnJmbmpJcbbmIEhv3BLb91dzCeOidy iFGag0VJnPfDW+cgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYy5bJNmn/raErl4XeW7qa1u c/ftMmY2vu+u2rmsuVz0ZM3z2L335rXczxLf/vInM2OC78Hp2qfPJ/Hlvz9hdVX9c33Pcr+w 3e3TSl8fsZx0byH7hpwvuq+iXdmDNhXcnC6bv96rd6+k2J965i0ln1482XXU7Na/g1/DLOpi J7hPeR/465uyyNzXSizFGYmGWsxFxYkAGf4mQkkCAAA= Subject: [clue] VC mandatory in MCC? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 10:02:05 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AC7E6ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When I indicate a MCC, do I have to list which VC(s) are associated with it= ? I may have an endpoint that e.g. requests a MCC with the most active speake= r of the whole conference, and it doesn't really care about which VC(s) are= used as "input" to the MCC. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4AC7E6ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When I indicate a MCC, do I have to list which VC(s)= are associated with it?

 

I may have an endpoint that e.g. requests a MCC with= the most active speaker of the whole conference, and it doesn’t real= ly care about which VC(s) are used as “input” to the MCC.<= /o:p>

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C4AC7E6ESESSMB209erics_-- From Christian.Groves@nteczone.com Thu Sep 26 06:04:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB6B21F8D20 for ; Thu, 26 Sep 2013 06:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HteZUSnC0GWx for ; Thu, 26 Sep 2013 06:04:01 -0700 (PDT) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:4]) by ietfa.amsl.com (Postfix) with ESMTP id F244921F8266 for ; Thu, 26 Sep 2013 06:03:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAKovRFJ20WeW/2dsb2JhbAANTsFqgnqBOYMZAQEBBDgbJRELGAkWDwkDAgECAUUGAQwIAQGxcZM7j1iEHgOtKw Received: from ppp118-209-103-150.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.103.150]) by ipmail04.adl6.internode.on.net with ESMTP; 26 Sep 2013 22:33:42 +0930 Message-ID: <524430A4.4020505@nteczone.com> Date: Thu, 26 Sep 2013 23:03:32 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg , "clue@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1C4AC7E6@ESESSMB209.ericsson.se> <52440FC7.4070206@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ACA93@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4ACA93@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] VC mandatory in MCC? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 13:04:01 -0000 Hello Christer, On 26/09/2013 10:11 PM, Christer Holmberg wrote: > Hi, > > >From an Advertiser point of view it can populate an MCC with what it likes with respect to the captures involved. It can choose which captures make up the MCC. It doesn't have to include the source captures if it doesn't want to. > > Ok. > >> Although this means that it can't indicate source capture specific attributes and the consumer looses the benefit of being able to configure based on that information. > Sure. But, I guess there can still be capture specific attributes for the MCC, so that I can configure things local to the MCU generating the MCC. [CNG] Yes there can still be MCC specific capture attributes. > >> All the consumer would know is that the MCC contains media from a number of unknown sources with the most active speaker being shown at any particular point in time. >> >> From a Consumer point of view if it receives a MCC with multiple VCs, it doesn't have to select any VCs in particular (although it can). All it needs to do is just return the MCC and an encoding. > Good. > > Regards, > > Christer Regards, Christian > > From Mark.Duckworth@polycom.com Thu Sep 26 10:29:54 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502C311E80DE for ; Thu, 26 Sep 2013 10:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnRAuRZPB7FR for ; Thu, 26 Sep 2013 10:29:49 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id F368221F9F3D for ; Thu, 26 Sep 2013 10:29:44 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Thu, 26 Sep 2013 10:29:37 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Thu, 26 Sep 2013 10:29:35 -0700 Thread-Topic: Example of MCC Thread-Index: Ac60HVr5sL20/Y6RQyiWjoalAQtPrQGu3f7A Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> References: <52391AD2.5000701@nteczone.com> In-Reply-To: <52391AD2.5000701@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 17:29:54 -0000 Hello Christian, Thanks for the example, this is a good basis for discussion. One new key concept here is that CapScene2 through CapScene7 include media = captures that are not associated with any encoding group. This indicates t= he consumer cannot ask for these captures directly in a configure message, = because there is no way for the consumer to ask for a capture encoding of a= ny of these captures directly. I have considered this idea before, and it = does seem useful. This MCC example is taking this approach with the MCU ad= vertising all the other endpoints' captures, to give information about them= , but not for directly putting into capture encodings sent from the MCU. However, there could be issues in scaling to large conferences. Here are t= wo points from draft-duckworth-clue-switching-example-01 (originally from d= raft-hansen-clue-consumer-layout): 1. The mixer could advertise all the other endpoint's captures, but as the = size of the conference increases the number of captures that must be advert= ised will quickly become impractical. 2. If the renderer had all the spatial information about all possible origi= nal source captures it might receive, it would enable correct spatial rende= ring. But as the number of captures per endpoint and the number of endpoint= s in a conference rise caching all the data becomes impractical. I'm not sure what the practical limit on conference size would be. Maybe t= here are reasonable ways to do this in large conferences. This needs furth= er thought. CapScene8 below is essentially the same idea as the "advertising multiple s= cenes" example in draft-duckworth-clue-switching-example-01, section 3.2. = CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft. I assum= e CapScene8 would include spatial information for MCC1, MCC2, and MCC3. An= d also I suggest CapScene8 could include other CSEs with fewer captures, su= ch as: MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures= :1}{Policy1}{Encodinggroup1} MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures= :1}{Policy1}{Encodinggroup2} MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures= :1}{Policy1}{Encodinggroup1} CSE9(MCC100,MCC101) CSE10(MCC102) These CSEs would be useful for one or two screen consumers. I have questions about how to use CapScene9 in the example below. Would MC= C4 through MCC12 have any spatial information? If so, what would it be? O= r does the consumer rely solely on the spatial information of VC4 through V= C15, along with some way of knowing which specific VC it is receiving (with= in an MCC encoding) at any given time? Would CapScene9 also include other CSEs with fewer media captures in them,= indicating a consumer could choose fewer media captures and still get a "r= epresentation of the whole scene" without receiving all 9 MCCs? Regards, Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Tuesday, September 17, 2013 11:16 PM > To: Duckworth, Mark; clue@ietf.org > Subject: Example of MCC >=20 > Hello Mark, >=20 > At yesterday's interim you asked if I could use the MCC concept > (draft-groves-clue-multi-content-00) to support the example in your draft= ( > draft-duckworth-clue-switching-example-01). I assume that you were talkin= g > about the scenario in section 2. >=20 > I think it is worthwhile to consider the "Endpoint" advertisements also. > From a CLUE perspective how an endpoint chooses to render the received > encodings is largely irrelevant as it is up to the local policy. >=20 > I would assume the source Advertisements would be something like: >=20 > Endpoint A - 4 screens, 3 cameras > Endpoint B - 3 screens, 3 cameras > Endpoint C - 3 screens, 3 cameras > Endpoint D - 3 screens, 3 cameras >=20 > Endpoints A-D: > CaptureScene1[Description=3DEndpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] >=20 > Endpoints E-G: > CaptureScene1[Description=3DEndpoint y,VC1,CSE(VC1)] >=20 > Note: The endpoints would be likely to use the same IDs in their respecti= ve > Advertisements. >=20 > Rather than considering what is displayed the MCC concepts concentrates > more on what the MCU/Mixer sends. The mixer doesn't know anything > about the number of screens an endpoint has. >=20 > My assumption from the figures is that if the 3 main screens are "site" > switching that there is one capture encoding/media stream for each. The > MCU switches in the applicable media into the stream based on voice activ= ity > [policy1]. I assume endpoint A will not see a capture from itself. The > descriptions are just for information. >=20 > Using the MCC concept the MCU would Advertise to endpoint A: > ----------------------------------------------------------- >=20 > CapScene2[Description=3DEndpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] >=20 > CapScene3[Description=3DEndpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] >=20 > CapScene4[Description=3DEndpoint > D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] >=20 > CapScene5[Description=3DEndpoint E,VC13,(CSE5(VC13)] >=20 > CapScene6[Description=3DEndpoint F,VC14,(CSE6(VC13)] >=20 > CapScene7[Description=3DEndpoint G,VC15,(CSE7(VC13)] >=20 > // The above part effectively is the same as the input advertisements. > There are no capture encodings associated with them. >=20 > CapScene8[Description=3DOutput3streammix, > MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} > {Encodinggroup1} > MCC2(VC5,VC8,VC11,VC13,VC14,VC15) > {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} > {Encodinggroup2} > MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} > {Encodinggroup3} > CSE8(MCC1,MCC2,MCC3) >=20 > // The above part describes the switched 3 main streams that relate to si= te > switching. MaxCaptures:1 indicates that only one capture from the MCC is > sent at a particular time. The default if it wasn't included is 1 so it d= oesn't > need to be sent but included for clarity. Sync-id:1 indicates that the so= urce > sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15 > nothing will be sent in the other MCCs. >=20 > CapScene9[Description=3DOutput9streams, > MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} >=20 > MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} >=20 > MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} >=20 > MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} >=20 > MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} >=20 > MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} >=20 > MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} >=20 > MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} >=20 > MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} >=20 > CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] >=20 > // The above part indicates that there are 9 capture encodings. Each of t= he > capture encodings may contain any captures from any source site with a > maximum of one capture at a time. Which capture is present is determined > by Policy2. >=20 > If the MCU wanted to provide a composed capture encoding of the 9 > captures it could Advertise in addition: > CapScene10[Description=3DNineTiles, > MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} > CSE(MCC13) > // As maxcaptures is 9 it indicates that the capture encoding contains > information from up to 9 sources at a time. >=20 > [CNG] The above arrangement allows a Consumer to understand how the > captures relate to the source sites. It means a Consumer can choose not t= o > receive information from a particular source. This is not possible accord= ing to > the "one big scene" approach below. >=20 > The Advertisement for Endpoint B in your draft would be identical to the > above other than the captures from Endpoint A would be added and the > captures from Endpoint B would be removed. >=20 > I hope this provides some clarification. >=20 > Regards, Christian From christer.holmberg@ericsson.com Thu Sep 26 12:24:04 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0091421F9C9A for ; Thu, 26 Sep 2013 12:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qyGmBIhBhoz for ; Thu, 26 Sep 2013 12:23:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 43A3421F9CF7 for ; Thu, 26 Sep 2013 12:23:53 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-38-524489c725b7 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 1E.45.22048.7C984425; Thu, 26 Sep 2013 21:23:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Thu, 26 Sep 2013 21:23:51 +0200 From: Christer Holmberg To: CLUE Thread-Topic: MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQ== Content-Class: urn:content-classes:message Date: Thu, 26 Sep 2013 19:23:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AD505ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvre6JTpcgg3e7WSz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAnHGtgLrvNXNE94z9rAOI23i5GTQ0LARKKt8zcLhC0mceHe erYuRi4OIYHDjBKtJ/uYIZwljBJPFi1l72Lk4GATsJDo/qcN0iAiICFx6tRdRhBbWEBUYuaa vewQcSmJb6+Xs0DYehJT+4+wgtjMAloSOybsYwQZwyKgKvG2QQgkzCvgK7F/02uwMYxAN3w/ tYYJolxc4taT+UwQtwlILNlznhnCFpV4+fgfK4StKPHx1T5GiPp8iWm7Z7FBzBSUODnzCcsE RuFZSDbPQjJ2FpKWWUhaIOJ6EjemTmGDsLUlli18zQxh60rM+HcIqsZa4tG+W0zIahYwcq5i ZM9NzMxJLzffxAiMnoNbfhvsYNx0X+wQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGEs9mOq1b/3cul3wsIPQKXGmgsQTsz56bk0ved3r3+liNc192d97eyJO5ha3XrfJ TmaSE1mz8bJxsJB89QXTb/+ndYed1dP38zDYeaDmrkR2xXLWXxe5V+x9UfuSSaFPjOO9v9Dn dQwOkn/srd6y5dVZFCc/fmhQvb7lQ1GGkfPdgA2HjSXTlViKMxINtZiLihMBVrwzZGwCAAA= Subject: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 19:24:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AD505ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, There are some examples of CSEs which contain MCCs (e.g. CSE8(MCC1,MCC2,MCC= 3)), but I guess it would also be possible to advertise MCCs that contain C= SEs (e.g MCC(CSE1, CSE2)). An example is when the MCC is composed of a whole capture scene entry. This is related to the discussion we previously had about simultaneous sets= , where I said that it should be possible to advertise, and select, an CSE,= rather than having to advertise and select each individual capture within. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4AD505ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <9E8E6E07389D8342893682B1DC240D3A@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

There are some examples of CSEs which contain MCCs (e.g. CSE8(MCC1,MCC2,= MCC3)), but I guess it would also be possible to advertise MCCs that contai= n CSEs (e.g MCC(CSE1, CSE2)).

 

An example is when the MCC is composed of a whole capture scene entry.

 

This is related to the discussion we previously had about simultaneous s= ets, where I said that it should be possible to advertise, and select, an C= SE, rather than having to advertise and select each individual capture with= in.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4AD505ESESSMB209erics_-- From Mark.Duckworth@polycom.com Thu Sep 26 13:04:32 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7123021F9AE6 for ; Thu, 26 Sep 2013 13:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU3aYesUXTM6 for ; Thu, 26 Sep 2013 13:04:27 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2AE21F9B60 for ; Thu, 26 Sep 2013 13:04:27 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Thu, 26 Sep 2013 13:04:26 -0700 From: "Duckworth, Mark" To: CLUE Date: Thu, 26 Sep 2013 13:04:25 -0700 Thread-Topic: MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJg Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.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_49E45C59CA48264997FEBFB29B6BC2D60333DFF1CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 20:04:32 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60333DFF1CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think it would add complication and confusion to allow this. If allowed,= it would be just a shorthand for saying "all the media captures in this CS= E can be included in this MCC". But it also opens the door for nested MCCs= (MCC includes a CSE that includes other MCCs), which doesn't make sense to= me, so I suggest we just avoid this shorthand. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: Thursday, September 26, 2013 3:24 PM To: CLUE Subject: [clue] MCC with CSE Hi, There are some examples of CSEs which contain MCCs (e.g. CSE8(MCC1,MCC2,MCC= 3)), but I guess it would also be possible to advertise MCCs that contain C= SEs (e.g MCC(CSE1, CSE2)). An example is when the MCC is composed of a whole capture scene entry. This is related to the discussion we previously had about simultaneous sets= , where I said that it should be possible to advertise, and select, an CSE,= rather than having to advertise and select each individual capture within. Regards, Christer --_000_49E45C59CA48264997FEBFB29B6BC2D60333DFF1CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think i= t would add complication and confusion to allow this.  If allowed, it = would be just a shorthand for saying “all the media captures in this = CSE can be included in this MCC”.  But it also opens the door fo= r nested MCCs (MCC includes a CSE that includes other MCCs), which doesn= 217;t make sense to me, so I suggest we just avoid this shorthand.

 

Mark

 

<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From: = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Ch= rister Holmberg
Sent: Thursday, September 26, 2013 3:24 PM
= To: CLUE
Subject: [clue] MCC with CSE

 

Hi,

 

There are some exam= ples of CSEs which contain MCCs (e.g. CSE8(MCC1,MCC2,MCC3)), but I guess it= would also be possible to advertise MCCs that contain CSEs (e.g MCC(CSE1, = CSE2)).

 

An e= xample is when the MCC is composed of a whole capture scene entry.

 

This is related to t= he discussion we previously had about simultaneous sets, where I said that = it should be possible to advertise, and select, an CSE, rather than having = to advertise and select each individual capture within.

 

Regards,

<= p> 

Christer

= --_000_49E45C59CA48264997FEBFB29B6BC2D60333DFF1CRPMBOXPRD07pol_-- From christer.holmberg@ericsson.com Thu Sep 26 13:13:36 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA6821E80AA for ; Thu, 26 Sep 2013 13:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.707 X-Spam-Level: X-Spam-Status: No, score=-5.707 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDXVfJFWhCRy for ; Thu, 26 Sep 2013 13:13:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2121F9C42 for ; Thu, 26 Sep 2013 13:13:29 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-bc-524495672f35 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D2.80.16099.76594425; Thu, 26 Sep 2013 22:13:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Thu, 26 Sep 2013 22:13:27 +0200 From: Christer Holmberg To: "Duckworth, Mark" , CLUE Thread-Topic: MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9w== Date: Thu, 26 Sep 2013 20:13:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AD717ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrW7GVJcgg7s7uS32n7rMbLHuyFNm ByaPJUt+Mnm8eKAUwBTFZZOSmpNZllqkb5fAlXF2537GgmbHijVru5gaGM+adzFyckgImEhs +bSZHcIWk7hwbz0biC0kcJhR4shmoy5GLiB7CaNE3+wHLF2MHBxsAhYS3f+0QWpEBDwktt2c wQRiCwtISsz4/poZIi4l8e31chYI20liytu9YDNZBFQlzi/+zQhi8wr4SnxufMsOMX8io8S9 oweZQeZzCgRIfHihAlLDCHTP91NrwOYzC4hL3HoynwniTgGJJXvOM0PYohIvH/9jhbAVJT6+ 2scIUZ8vcefAHhaIXYISJ2c+YZnAKDILyahZSMpmISmDiBtIvD83nxnC1pZYtvA1lK0vsfHL WUYI21pi+5RmFmQ1Cxg5VjGy5yZm5qSXG25iBMbTwS2/dXcwnjoncohRmoNFSZz3w1vnICGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2MxdvfrGuy+rNigsW1gut9/TL3q0+99Ih9rdWe+Ne2 oED204a/QTe7HgU83XrmwpvZn37827z//NcZrzoXTdoRFtA/w9zT/4uBf6n1q1S1Tg+hzRGf uVV2GR2/Vi1VsCjUO+1B6gUG3Q/nzPd3nmYpcVKb0bNUN2TWzIxJIs8muHFbdk81XTvHRoml OCPRUIu5qDgRAIHAVxl1AgAA Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 20:13:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AD717ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, It's up to the advertiser to make sure it doesn't advertise things that it = can't provide. The MCU may request a specific CSE from an endpoint, and then advertise tha= t as a composed MCC to another endpoint. I don't see why the MCU should hav= e to advertise the VCs associated with that CSE, when it can simply adverti= se the CSE. Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Duckworth,= Mark [Mark.Duckworth@polycom.com] Sent: Thursday, 26 September 2013 11:04 PM To: CLUE Subject: Re: [clue] MCC with CSE I think it would add complication and confusion to allow this. If allowed,= it would be just a shorthand for saying =93all the media captures in this = CSE can be included in this MCC=94. But it also opens the door for nested = MCCs (MCC includes a CSE that includes other MCCs), which doesn=92t make se= nse to me, so I suggest we just avoid this shorthand. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: Thursday, September 26, 2013 3:24 PM To: CLUE Subject: [clue] MCC with CSE Hi, There are some examples of CSEs which contain MCCs (e.g. CSE8(MCC1,MCC2,MCC= 3)), but I guess it would also be possible to advertise MCCs that contain C= SEs (e.g MCC(CSE1, CSE2)). An example is when the MCC is composed of a whole capture scene entry. This is related to the discussion we previously had about simultaneous sets= , where I said that it should be possible to advertise, and select, an CSE,= rather than having to advertise and select each individual capture within. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4AD717ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2204894DAB0C5E4B8ED3EF0351256DE6@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

It's up to the advertiser to make sure it doesn't advertise things that = it can't provide.

 

The MCU may request a specific CSE from an endpoint, and then advertise = that as a composed MCC to another endpoint. I don't see why the MCU should = have to advertise the VCs associated with that CSE, when it can simply adve= rtise the CSE.

 

Regards,

 

Christer

 

 

From: clue-bounces@ietf.org [clue-bounces= @ietf.org] on behalf of Duckworth, Mark [Mark.Duckworth@polycom.com]
Sent: Thursday, 26 September 2013 11:04 PM
To: CLUE
Subject: Re: [clue] MCC with CSE

I think it w= ould add complication and confusion to allow this.  If allowed, it wou= ld be just a shorthand for saying =93all the media captures in this CSE can be included in this MCC=94.  But it also opens the door = for nested MCCs (MCC includes a CSE that includes other MCCs), which doesn= =92t make sense to me, so I suggest we just avoid this shorthand.

 

Mark<= /p>

 

From: clue= -bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, September 26, 2013 3:24 PM
To: CLUE
Subject: [clue] MCC with CSE

 

Hi,

 

There are some examples of CSEs which contai= n MCCs (e.g. CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible t= o advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)).

 

An example is when the MCC is composed of a = whole capture scene entry.

 

This is related to the discussion we previou= sly had about simultaneous sets, where I said that it should be possible to= advertise, and select, an CSE, rather than having to advertise and select each individual capture within.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1C4AD717ESESSMB209erics_-- From Christian.Groves@nteczone.com Thu Sep 26 17:57:48 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5EC21F9DFC for ; Thu, 26 Sep 2013 17:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVZx+zowS600 for ; Thu, 26 Sep 2013 17:57:48 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id E1A2021F9D7E for ; Thu, 26 Sep 2013 17:57:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBALDXRFJ20dxg/2dsb2JhbAANToM/wR2BMIMZAQEBBAEBAS8BBRsbChELEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiA6pO5MpBI9YBhCECAOtKw Received: from ppp118-209-220-96.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.220.96]) by ipmail06.adl2.internode.on.net with ESMTP; 27 Sep 2013 10:27:21 +0930 Message-ID: <5244D7DC.6080005@nteczone.com> Date: Fri, 27 Sep 2013 10:57:00 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 00:57:48 -0000 Hello Christer, I had considered this issue when putting together the proposal and decided that a CSE should be in a MCC. The idea behind the MCC was that it was a capture. Captures go in CSEs not the other way around. As Mark mentioned using CSEs inside MCCs would lead to nesting issues i.e. CS,CSE,MCC,CSE. Also CSEs have a certain semantic that is that all the captures in the CSE make up one representation of a scene. It shouldn't be seen (pardon the pun) that CSEs is a syntax shorthand. I think there are other options for minimising message size. Regards, Christian On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > Hi, > > It's up to the advertiser to make sure it doesn't advertise things > that it can't provide. > > The MCU may request a specific CSE from an endpoint, and then > advertise that as a composed MCC to another endpoint. I don't see why > the MCU should have to advertise the VCs associated with that CSE, > when it can simply advertise the CSE. > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com] > *Sent:* Thursday, 26 September 2013 11:04 PM > *To:* CLUE > *Subject:* Re: [clue] MCC with CSE > > I think it would add complication and confusion to allow this. If > allowed, it would be just a shorthand for saying “all the media > captures in this CSE can be included in this MCC”. But it also opens > the door for nested MCCs (MCC includes a CSE that includes other > MCCs), which doesn’t make sense to me, so I suggest we just avoid this > shorthand. > > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Thursday, September 26, 2013 3:24 PM > *To:* CLUE > *Subject:* [clue] MCC with CSE > > Hi, > > There are some examples of CSEs which contain MCCs (e.g. > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > An example is when the MCC is composed of a whole capture scene entry. > > This is related to the discussion we previously had about simultaneous > sets, where I said that it should be possible to advertise, and > select, an CSE, rather than having to advertise and select each > individual capture within. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Thu Sep 26 18:43:34 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D0C21E80D4 for ; Thu, 26 Sep 2013 18:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhguMgM-99Nl for ; Thu, 26 Sep 2013 18:43:28 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 876AD21F99D5 for ; Thu, 26 Sep 2013 18:43:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBADriRFJ20dxg/2dsb2JhbAANTsRTCYExgxkBAQEDATgbFRABDAQLEQQBAQEJFggHCQMCAQIBNAkIBg0BBQIBAYd8qESTLY4TgT4HBoQYA60rgVYBBg Received: from ppp118-209-220-96.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.220.96]) by ipmail06.adl2.internode.on.net with ESMTP; 27 Sep 2013 11:13:11 +0930 Message-ID: <5244E2A7.8020601@nteczone.com> Date: Fri, 27 Sep 2013 11:43:03 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Duckworth, Mark" References: <52391AD2.5000701@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "clue@ietf.org" Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 01:43:34 -0000 Hello Mark, Please see my responses below. Regards, Christian On 27/09/2013 3:29 AM, Duckworth, Mark wrote: > Hello Christian, > > Thanks for the example, this is a good basis for discussion. > > One new key concept here is that CapScene2 through CapScene7 include media captures that are not associated with any encoding group. This indicates the consumer cannot ask for these captures directly in a configure message, because there is no way for the consumer to ask for a capture encoding of any of these captures directly. I have considered this idea before, and it does seem useful. This MCC example is taking this approach with the MCU advertising all the other endpoints' captures, to give information about them, but not for directly putting into capture encodings sent from the MCU. [CNG] Yes that's correct. > > However, there could be issues in scaling to large conferences. Here are two points from draft-duckworth-clue-switching-example-01 (originally from draft-hansen-clue-consumer-layout): > > 1. The mixer could advertise all the other endpoint's captures, but as the size of the conference increases the number of captures that must be advertised will quickly become impractical. > 2. If the renderer had all the spatial information about all possible original source captures it might receive, it would enable correct spatial rendering. But as the number of captures per endpoint and the number of endpoints in a conference rise caching all the data becomes impractical. [CNG] I think the above are just a natural consequence that as the number of endpoints increase so will the amount of information that needs to be signalled. I think the key point is that with the MCC concept the MCU has to choice to provide as much or as little information as it wants. It doesn't have to pass on all the information that it receives in the source captures, it can filter or manipulate the information as it sees fit. With regards to the 2nd point the MCC concept allows the MCU to provide "harmonised" spatial information regarding the MCC which means the a Consumer could use this information rather than source spatial information if conference size becomes a problem. > > I'm not sure what the practical limit on conference size would be. Maybe there are reasonable ways to do this in large conferences. This needs further thought. [CNG] I don't see that CLUE needs to place any limits on the conference size. I think its largely an endpoint decision on the amount of information it wants to provide. I think there are potential optimisation we can do in the coding of CLUE that will minimise the size of messages. For example introducing a "range" concept to CSEs/MCCs/STSs that could allow to specify a group of captures without specifying every one. MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} could be signalled as: MCC100(VC4-VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} Likewise a CSE for CaptureScene9 CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12) could be signalled as: CSE(MCC4-MCC12) > > CapScene8 below is essentially the same idea as the "advertising multiple scenes" example in draft-duckworth-clue-switching-example-01, section 3.2. CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft. I assume CapScene8 would include spatial information for MCC1, MCC2, and MCC3. And also I suggest CapScene8 could include other CSEs with fewer captures, such as: > MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} > MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup2} > MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} > CSE9(MCC100,MCC101) > CSE10(MCC102) > These CSEs would be useful for one or two screen consumers. [CNG] Yes multiple Capture Scenes are used so this aspect parallels section 3.2 in your draft. Yes I agree that Capture8 could include CSEs with fewer captures as you suggest. > > I have questions about how to use CapScene9 in the example below. Would MCC4 through MCC12 have any spatial information? If so, what would it be? Or does the consumer rely solely on the spatial information of VC4 through VC15, along with some way of knowing which specific VC it is receiving (within an MCC encoding) at any given time? [CNG] Potentially MCC4 through MCC12 could have spatial information. An advertiser could supply the same "virtual" capture area on each MCC (i.e. a MCU may do some image processing to ensure they captures are the same size) that way the consumer knows the MCCs are the same size. Alternatively the MCC could change the location of the capture areas in virtual space to suggest some sort of layout to a consumer. The 3rd option is not to send spatial information. The above would be the switching case. In a composition case the Advertiser could provide a "harmonised" virtual capture area on the MCC and it could provide capture area information on the individual VCs to give their layout in the "harmonised" capture area. > > Would CapScene9 also include other CSEs with fewer media captures in them, indicating a consumer could choose fewer media captures and still get a "representation of the whole scene" without receiving all 9 MCCs? [CNG] CapScene9 could include CSEs with fewer captures. It would come down to whether the Advertiser considers MCC4-MCC12 (or a subset of) as representations of the overall scene or just as individual supplementary streams. > > Regards, > Mark > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Tuesday, September 17, 2013 11:16 PM >> To: Duckworth, Mark; clue@ietf.org >> Subject: Example of MCC >> >> Hello Mark, >> >> At yesterday's interim you asked if I could use the MCC concept >> (draft-groves-clue-multi-content-00) to support the example in your draft ( >> draft-duckworth-clue-switching-example-01). I assume that you were talking >> about the scenario in section 2. >> >> I think it is worthwhile to consider the "Endpoint" advertisements also. >> From a CLUE perspective how an endpoint chooses to render the received >> encodings is largely irrelevant as it is up to the local policy. >> >> I would assume the source Advertisements would be something like: >> >> Endpoint A - 4 screens, 3 cameras >> Endpoint B - 3 screens, 3 cameras >> Endpoint C - 3 screens, 3 cameras >> Endpoint D - 3 screens, 3 cameras >> >> Endpoints A-D: >> CaptureScene1[Description=Endpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] >> >> Endpoints E-G: >> CaptureScene1[Description=Endpoint y,VC1,CSE(VC1)] >> >> Note: The endpoints would be likely to use the same IDs in their respective >> Advertisements. >> >> Rather than considering what is displayed the MCC concepts concentrates >> more on what the MCU/Mixer sends. The mixer doesn't know anything >> about the number of screens an endpoint has. >> >> My assumption from the figures is that if the 3 main screens are "site" >> switching that there is one capture encoding/media stream for each. The >> MCU switches in the applicable media into the stream based on voice activity >> [policy1]. I assume endpoint A will not see a capture from itself. The >> descriptions are just for information. >> >> Using the MCC concept the MCU would Advertise to endpoint A: >> ----------------------------------------------------------- >> >> CapScene2[Description=Endpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] >> >> CapScene3[Description=Endpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] >> >> CapScene4[Description=Endpoint >> D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] >> >> CapScene5[Description=Endpoint E,VC13,(CSE5(VC13)] >> >> CapScene6[Description=Endpoint F,VC14,(CSE6(VC13)] >> >> CapScene7[Description=Endpoint G,VC15,(CSE7(VC13)] >> >> // The above part effectively is the same as the input advertisements. >> There are no capture encodings associated with them. >> >> CapScene8[Description=Output3streammix, >> MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} >> {Encodinggroup1} >> MCC2(VC5,VC8,VC11,VC13,VC14,VC15) >> {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} >> {Encodinggroup2} >> MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} >> {Encodinggroup3} >> CSE8(MCC1,MCC2,MCC3) >> >> // The above part describes the switched 3 main streams that relate to site >> switching. MaxCaptures:1 indicates that only one capture from the MCC is >> sent at a particular time. The default if it wasn't included is 1 so it doesn't >> need to be sent but included for clarity. Sync-id:1 indicates that the source >> sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15 >> nothing will be sent in the other MCCs. >> >> CapScene9[Description=Output9streams, >> MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} >> >> MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} >> >> MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} >> >> MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} >> >> MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} >> >> MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} >> >> MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} >> >> MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} >> >> MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} >> >> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] >> >> // The above part indicates that there are 9 capture encodings. Each of the >> capture encodings may contain any captures from any source site with a >> maximum of one capture at a time. Which capture is present is determined >> by Policy2. >> >> If the MCU wanted to provide a composed capture encoding of the 9 >> captures it could Advertise in addition: >> CapScene10[Description=NineTiles, >> MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >> VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} >> CSE(MCC13) >> // As maxcaptures is 9 it indicates that the capture encoding contains >> information from up to 9 sources at a time. >> >> [CNG] The above arrangement allows a Consumer to understand how the >> captures relate to the source sites. It means a Consumer can choose not to >> receive information from a particular source. This is not possible according to >> the "one big scene" approach below. >> >> The Advertisement for Endpoint B in your draft would be identical to the >> above other than the captures from Endpoint A would be added and the >> captures from Endpoint B would be removed. >> >> I hope this provides some clarification. >> >> Regards, Christian From christer.holmberg@ericsson.com Fri Sep 27 04:59:43 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41FB221F9CE8 for ; Fri, 27 Sep 2013 04:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.414 X-Spam-Level: X-Spam-Status: No, score=-5.414 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0+6rD8-0SGg for ; Fri, 27 Sep 2013 04:59:38 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 620FC21F9A70 for ; Fri, 27 Sep 2013 04:59:37 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-1a-524573285629 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6E.09.22048.82375425; Fri, 27 Sep 2013 13:59:36 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 13:59:35 +0200 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQ== Date: Fri, 27 Sep 2013 11:59:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> In-Reply-To: <5244D7DC.6080005@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4ADDA5ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvra5GsWuQweRzwhZf3jeyWOw/dZnZ gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mp42/6fqaA3tGLz53fsDYw9bl2MnBwSAiYS K189ZoewxSQu3FvP1sXIxSEkcJhRYm/TMVYIZwmjxPpF51i6GDk42AQsJLr/aYM0iAiES3Rs u8IIYgsLKEi8f7GTGSKuKPH32w52CDtM4kfvHDCbRUBVornxG1g9r4CvxLHfj9gh5v9glHj+ bi1YEaeAjkTHru9MIDYj0EXfT60Bs5kFxCVuPZnPBHGpgMSSPeeZIWxRiZeP/7FC2IoSH1/t Y4Soz5fo/LCADWKZoMTJmU9YJjCKzEIyahaSsllIyiDiBhLvz81nhrC1JZYtfA1l60ts/HKW EcK2lpgzcz87spoFjByrGNlzEzNz0svNNzECo+rglt8GOxg33Rc7xCjNwaIkzvvhrXOQkEB6 YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbsJrtXwnd2H3v1xuaV9P8VBp2zr3x3P8ze9vV+nJaW zZOlrVfPMOvW3T2/TvS57qb0/OOL+Q8KmrrvXWVx1mLb8YA5ostP+HRGG9rozU97OfOC987M 2VvuvRUu+vNtl7bYt4BpJbMen01/qW+2wSsz7B/DAcvnbc/0dlw8Mu/s1EPvQi1/3woRVGIp zkg01GIuKk4EAFokZF54AgAA Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 11:59:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4ADDA5ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, The currently proposal works when the content of an MCC is one or more indi= vidual VCs, which the receiver can choose. That works fine when the MCU doe= s switching. But, in my opinion it does not work for composed MCCs, where the content of= the MCC can be built based on multiple Take an example: - in a conference, each site provides a CSE which contains two VCs: one wit= h main video, and one with slides/screen sharing. - the MCU wants to provide, at any given time, one of these CSEs (the selec= tion might be based on active speaker, or whatever) is a single stream towa= rds an endpoint. So, it advertises an "main-slide CSE from the site with th= e active speaker site" MCC. Now, I don't want the receiver to receive all the VCs, from the different s= ites, and try to figure out which belong toghether etc. And, the more VCs a= n CSE consist of, the more complicated it gets. Now, having said that, I DO agree that we should try to keep the "hiearchy"= . So, in this case, maybe we should introduce a Mixed CSE (MCSE) concept. The= MCU could then offer a "most active site" MCSE, in which it lists the MCC.= Something like: MCSE1(MCC1{Policy SceneWithTheActiveSpeaker}) Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Christian = Groves [Christian.Groves@nteczone.com] Sent: Friday, 27 September 2013 3:57 AM To: clue@ietf.org Subject: Re: [clue] MCC with CSE Hello Christer, I had considered this issue when putting together the proposal and decided that a CSE should be in a MCC. The idea behind the MCC was that it was a capture. Captures go in CSEs not the other way around. As Mark mentioned using CSEs inside MCCs would lead to nesting issues i.e. CS,CSE,MCC,CSE. Also CSEs have a certain semantic that is that all the captures in the CSE make up one representation of a scene. It shouldn't be seen (pardon the pun) that CSEs is a syntax shorthand. I think there are other options for minimising message size. Regards, Christian On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > Hi, > > It's up to the advertiser to make sure it doesn't advertise things > that it can't provide. > > The MCU may request a specific CSE from an endpoint, and then > advertise that as a composed MCC to another endpoint. I don't see why > the MCU should have to advertise the VCs associated with that CSE, > when it can simply advertise the CSE. > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com] > *Sent:* Thursday, 26 September 2013 11:04 PM > *To:* CLUE > *Subject:* Re: [clue] MCC with CSE > > I think it would add complication and confusion to allow this. If > allowed, it would be just a shorthand for saying =93all the media > captures in this CSE can be included in this MCC=94. But it also opens > the door for nested MCCs (MCC includes a CSE that includes other > MCCs), which doesn=92t make sense to me, so I suggest we just avoid this > shorthand. > > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Thursday, September 26, 2013 3:24 PM > *To:* CLUE > *Subject:* [clue] MCC with CSE > > Hi, > > There are some examples of CSEs which contain MCCs (e.g. > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > An example is when the MCC is composed of a whole capture scene entry. > > This is related to the discussion we previously had about simultaneous > sets, where I said that it should be possible to advertise, and > select, an CSE, rather than having to advertise and select each > individual capture within. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1C4ADDA5ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

The currently proposal works when the content of an MCC is one or more i= ndividual VCs, which the receiver can choose. That works fine when the MCU = does switching.

 

But, in my opinion it does not work for composed MCCs, where the content= of the MCC can be built based on multiple

 

 

Take an example:

 

- in a conference, each site provides a CSE which contains two VCs: one = with main video, and one with slides/screen sharing.

 

- the MCU wants to provide, at any given time, one of these CSEs (the se= lection might be based on active speaker, or whatever) is a single str= eam towards an endpoint. So, it advertises an "main-slide CSE from the= site with the active speaker site" MCC.

 

Now, I don't want the receiver to receive all the VCs, from the differen= t sites, and try to figure out which belong toghether etc. And, the more VC= s an CSE consist of, the more complicated it gets.

 

 

Now, having said that, I DO agree that we should try to keep the "h= iearchy".

 

So, in this case, maybe we should introduce a Mixed CSE (MCSE) concept. = The MCU could then offer a "most active site" MCSE, in which it l= ists the MCC. Something like: MCSE1(MCC1{Policy SceneWithTheActiveSpeaker})=

 

Regards,

 

Christer

 

 

 

 

From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of= Christian Groves [Christian.Groves@nteczone.com]
Sent: Friday, 27 September 2013 3:57 AM
To: clue@ietf.org
Subject: Re: [clue] MCC with CSE

Hello Christer,

I had considered this issue when putting together the proposal and
decided that a CSE should be in a MCC. The idea behind the MCC was that it was a capture. Captures go in CSEs not the other way around. As Mark mentioned using CSEs inside MCCs would lead to nesting issues i.e.
CS,CSE,MCC,CSE.

Also CSEs have a certain semantic that is that all the captures in the
CSE make up one representation of a scene. It shouldn't be seen (pardon the pun) that CSEs is a syntax shorthand. I think there are other
options for minimising message size.

Regards, Christian

On 27/09/2013 6:13 AM, Christer Holmberg wrote:
>
> Hi,
>
> It's up to the advertiser to make sure it doesn't advertise things > that it can't provide.
>
> The MCU may request a specific CSE from an endpoint, and then
> advertise that as a composed MCC to another endpoint. I don't see why =
> the MCU should have to advertise the VCs associated with that CSE, > when it can simply advertise the CSE.
>
> Regards,
>
> Christer
>
> ----------------------------------------------------------------------= --
> *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com]
> *Sent:* Thursday, 26 September 2013 11:04 PM
> *To:* CLUE
> *Subject:* Re: [clue] MCC with CSE
>
> I think it would add complication and confusion to allow this. If
> allowed, it would be just a shorthand for saying =93all the media
> captures in this CSE can be included in this MCC=94. But it also opens=
> the door for nested MCCs (MCC includes a CSE that includes other
> MCCs), which doesn=92t make sense to me, so I suggest we just avoid th= is
> shorthand.
>
> Mark
>
> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf
> Of *Christer Holmberg
> *Sent:* Thursday, September 26, 2013 3:24 PM
> *To:* CLUE
> *Subject:* [clue] MCC with CSE
>
> Hi,
>
> There are some examples of CSEs which contain MCCs (e.g.
> CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to
> advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)).
>
> An example is when the MCC is composed of a whole capture scene entry.=
>
> This is related to the discussion we previously had about simultaneous=
> sets, where I said that it should be possible to advertise, and
> select, an CSE, rather than having to advertise and select each
> individual capture within.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue
--_000_7594FB04B1934943A5C02806D1A2204B1C4ADDA5ESESSMB209erics_-- From Mark.Duckworth@polycom.com Fri Sep 27 07:25:45 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CFD21E8097 for ; Fri, 27 Sep 2013 07:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJGNGnw+E6WO for ; Fri, 27 Sep 2013 07:25:41 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id BE3D221E808D for ; Fri, 27 Sep 2013 07:25:40 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 27 Sep 2013 07:25:37 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 27 Sep 2013 07:25:35 -0700 Thread-Topic: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQAE9KCQ Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.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_49E45C59CA48264997FEBFB29B6BC2D60333E1A4CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 14:25:45 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60333E1A4CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer, I don't understand why in your example the MCU would want to advertise an M= CC at all. Comments below. Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Chr= ister Holmberg Sent: Friday, September 27, 2013 8:00 AM To: Christian Groves; clue@ietf.org Subject: Re: [clue] MCC with CSE Hi, The currently proposal works when the content of an MCC is one or more indi= vidual VCs, which the receiver can choose. That works fine when the MCU doe= s switching. But, in my opinion it does not work for composed MCCs, where the content of= the MCC can be built based on multiple Take an example: - in a conference, each site provides a CSE which contains two VCs: one wit= h main video, and one with slides/screen sharing. - the MCU wants to provide, at any given time, one of these CSEs (the selec= tion might be based on active speaker, or whatever) is a single stream towa= rds an endpoint. So, it advertises an "main-slide CSE from the site with th= e active speaker site" MCC. Now, I don't want the receiver to receive all the VCs, from the different s= ites, and try to figure out which belong toghether etc. And, the more VCs a= n CSE consist of, the more complicated it gets. [Duckworth, Mark] If the MCU does not want to advertise anything about the = other endpoint's VCs, then what is the point of using an MCC at all? In th= is case, the MCU should simply advertise a composed VC. Now, having said that, I DO agree that we should try to keep the "hiearchy"= . So, in this case, maybe we should introduce a Mixed CSE (MCSE) concept. The= MCU could then offer a "most active site" MCSE, in which it lists the MCC.= Something like: MCSE1(MCC1{Policy SceneWithTheActiveSpeaker}) Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Christian = Groves [Christian.Groves@nteczone.com] Sent: Friday, 27 September 2013 3:57 AM To: clue@ietf.org Subject: Re: [clue] MCC with CSE Hello Christer, I had considered this issue when putting together the proposal and decided that a CSE should be in a MCC. The idea behind the MCC was that it was a capture. Captures go in CSEs not the other way around. As Mark mentioned using CSEs inside MCCs would lead to nesting issues i.e. CS,CSE,MCC,CSE. Also CSEs have a certain semantic that is that all the captures in the CSE make up one representation of a scene. It shouldn't be seen (pardon the pun) that CSEs is a syntax shorthand. I think there are other options for minimising message size. Regards, Christian On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > Hi, > > It's up to the advertiser to make sure it doesn't advertise things > that it can't provide. > > The MCU may request a specific CSE from an endpoint, and then > advertise that as a composed MCC to another endpoint. I don't see why > the MCU should have to advertise the VCs associated with that CSE, > when it can simply advertise the CSE. > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces= @ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com] > *Sent:* Thursday, 26 September 2013 11:04 PM > *To:* CLUE > *Subject:* Re: [clue] MCC with CSE > > I think it would add complication and confusion to allow this. If > allowed, it would be just a shorthand for saying "all the media > captures in this CSE can be included in this MCC". But it also opens > the door for nested MCCs (MCC includes a CSE that includes other > MCCs), which doesn't make sense to me, so I suggest we just avoid this > shorthand. > > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Thursday, September 26, 2013 3:24 PM > *To:* CLUE > *Subject:* [clue] MCC with CSE > > Hi, > > There are some examples of CSEs which contain MCCs (e.g. > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > An example is when the MCC is composed of a whole capture scene entry. > > This is related to the discussion we previously had about simultaneous > sets, where I said that it should be possible to advertise, and > select, an CSE, rather than having to advertise and select each > individual capture within. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_49E45C59CA48264997FEBFB29B6BC2D60333E1A4CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christ= er,

I don’t understa= nd why in your example the MCU would want to advertise an MCC at all. = Comments below.

Mark=

 

From: clue-bounces@ietf.org [mailto:c= lue-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent:= Friday, September 27, 2013 8:00 AM
To: Christian Groves; clue@ie= tf.org
Subject: Re: [clue] MCC with CSE

 

Hi,

 

The currently proposa= l works when the content of an MCC is one or more individual VCs, which the= receiver can choose. That works fine when the MCU does switching.

 

But, in my opinion i= t does not work for composed MCCs, where the content of the MCC can be buil= t based on multiple

 

 

Take an example:

 

- in a conference, each s= ite provides a CSE which contains two VCs: one with main video, and one wit= h slides/screen sharing.

 

- the MCU wants to provide, at any given time, one of these CS= Es (the selection might be based on active speaker, or whatever) is a = single stream towards an endpoint. So, it advertises an "main-slide CS= E from the site with the active speaker site" MCC.

 

Now, I don't want the receiver = to receive all the VCs, from the different sites, and try to figure out whi= ch belong toghether etc. And, the more VCs an CSE consist of, the more comp= licated it gets.

 

[Duckworth, Mark] If the MCU does not want t= o advertise anything about the other endpoint’s VCs, then what is the= point of using an MCC at all?  In this case, the MCU should simply ad= vertise a composed VC.

 = ;

Now, having said that, I DO agree that we sho= uld try to keep the "hiearchy".

 = ;

So, in this case, maybe we should introduce a= Mixed CSE (MCSE) concept. The MCU could then offer a "most active sit= e" MCSE, in which it lists the MCC. Something like: MCSE1(MCC1{Policy = SceneWithTheActiveSpeaker})

 

Regards,

 

Christer

 <= /p>

 

 

 

From: clue-bounces@ietf.org [clue-= bounces@ietf.org] on behalf of Christian Groves [Christian.Groves@nteczone.= com]
Sent: Friday, 27 September 2013 3:57 AM
To: clue@i= etf.org
Subject: Re: [clue] MCC with CSE

Hello Christer,

I had conside= red this issue when putting together the proposal and
decided that a CS= E should be in a MCC. The idea behind the MCC was that
it was a capture= . Captures go in CSEs not the other way around. As Mark
mentioned using= CSEs inside MCCs would lead to nesting issues i.e.
CS,CSE,MCC,CSE.
=
Also CSEs have a certain semantic that is that all the captures in the =
CSE make up one representation of a scene. It shouldn't be seen (pardon=
the pun) that CSEs is a syntax shorthand. I think there are other
= options for minimising message size.

Regards, Christian

On 27= /09/2013 6:13 AM, Christer Holmberg wrote:
>
> Hi,
>
&= gt; It's up to the advertiser to make sure it doesn't advertise things
= > that it can't provide.
>
> The MCU may request a specific = CSE from an endpoint, and then
> advertise that as a composed MCC to= another endpoint. I don't see why
> the MCU should have to advertis= e the VCs associated with that CSE,
> when it can simply advertise t= he CSE.
>
> Regards,
>
> Christer
>
> -= -----------------------------------------------------------------------
= > *From:* clue-bounces@ietf.org= [clue-bounces@ietf.org] on behalf of
> Duckworth, Mark [Mark.Du= ckworth@polycom.com]
> *Sent:* Thursday, 26 September 2013 11:04 PM> *To:* CLUE
> *Subject:* Re: [clue] MCC with CSE
>
>= ; I think it would add complication and confusion to allow this. If
>= ; allowed, it would be just a shorthand for saying “all the media > captures in this CSE can be included in this MCC”. But it also = opens
> the door for nested MCCs (MCC includes a CSE that includes o= ther
> MCCs), which doesn’t make sense to me, so I suggest we = just avoid this
> shorthand.
>
> Mark
>
> *F= rom:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf
> Of *Chris= ter Holmberg
> *Sent:* Thursday, September 26, 2013 3:24 PM
> *= To:* CLUE
> *Subject:* [clue] MCC with CSE
>
> Hi,
>= ;
> There are some examples of CSEs which contain MCCs (e.g.
>= CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to
> a= dvertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)).
>
> An e= xample is when the MCC is composed of a whole capture scene entry.
><= br>> This is related to the discussion we previously had about simultane= ous
> sets, where I said that it should be possible to advertise, an= d
> select, an CSE, rather than having to advertise and select each =
> individual capture within.
>
> Regards,
>
>= ; Christer
>
>
>
> ________________________________= _______________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue<= /a>

_______________________________________________
clue mailing = list
clue@ietf.org
https://www.iet= f.org/mailman/listinfo/clue

= --_000_49E45C59CA48264997FEBFB29B6BC2D60333E1A4CRPMBOXPRD07pol_-- From Mark.Duckworth@polycom.com Fri Sep 27 08:04:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DC021E80F8 for ; Fri, 27 Sep 2013 08:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eevt9QGfIXL for ; Fri, 27 Sep 2013 08:04:25 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 31E4F21E80F5 for ; Fri, 27 Sep 2013 08:04:22 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 27 Sep 2013 08:04:16 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Fri, 27 Sep 2013 08:04:14 -0700 Thread-Topic: Example of MCC Thread-Index: Ac67IvgTmZzm+ItuSAqtPWYcdDgB9QAa5iDA Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60333E1FB@CRPMBOXPRD07.polycom.com> References: <52391AD2.5000701@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> <5244E2A7.8020601@nteczone.com> In-Reply-To: <5244E2A7.8020601@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 15:04:34 -0000 Hi Christian, I agree the MCU provider can choose to provide as much or as little informa= tion as it wants. And I agree there could be optimizations to reduce CLUE = message sizes. Given this, maybe it is enough to address the concerns abou= t scaling to large conferences? What do others think? About CapScene9, I have more questions. You suggested the MCU could do som= e image processing to ensure captures are the same size, and indicate this = by using the same virtual area of capture for each of the MCCs. I agree, b= ut I was not too concerned about the relative sizes of the captures from di= fferent endpoints. I am more concerned about the spatial relationship betw= een captures from the same endpoint in terms of how to order them next to e= ach other for proper rendering. The consumer should have enough informatio= n to do this if the MCU provides all the original spatial information from = each endpoint in the advertisement, do you agree? One downside to this approach is that every change the MCU makes in how it = assigns contributing VCs to an MCC (e.g. make a switch based on current tal= ker) could result in the consumer renderer needing to change how it maps de= coder output to display locations. I need to think more about if this woul= d really be a problem or not. In my example (section 3.2 of my draft) I at= tempted to address this by using multiple scenes, where each scene had fewe= r VCs (these could become MCCs) in each CSE, with some spatial information = the MCU would adhere to when switching. I'm still leaning toward this mult= iple scene idea. I think combining it with the MCC concept will be an impr= ovement. Still about CapScene9, you wrote "the MCC could change the location of the = capture areas in virtual space to suggest some sort of layout to a consumer= . The 3rd option is not to send spatial information." I don't understand w= hat you mean, could you expand on this please? Regards, Mark > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@nteczone.com] > Sent: Thursday, September 26, 2013 9:43 PM > To: Duckworth, Mark > Cc: clue@ietf.org > Subject: Re: Example of MCC >=20 > Hello Mark, >=20 > Please see my responses below. >=20 > Regards, Christian >=20 > On 27/09/2013 3:29 AM, Duckworth, Mark wrote: > > Hello Christian, > > > > Thanks for the example, this is a good basis for discussion. > > > > One new key concept here is that CapScene2 through CapScene7 include > media captures that are not associated with any encoding group. This > indicates the consumer cannot ask for these captures directly in a config= ure > message, because there is no way for the consumer to ask for a capture > encoding of any of these captures directly. I have considered this idea > before, and it does seem useful. This MCC example is taking this approac= h > with the MCU advertising all the other endpoints' captures, to give > information about them, but not for directly putting into capture encodin= gs > sent from the MCU. > [CNG] Yes that's correct. > > > > However, there could be issues in scaling to large conferences. Here a= re > two points from draft-duckworth-clue-switching-example-01 (originally fro= m > draft-hansen-clue-consumer-layout): > > > > 1. The mixer could advertise all the other endpoint's captures, but as = the > size of the conference increases the number of captures that must be > advertised will quickly become impractical. > > 2. If the renderer had all the spatial information about all possible o= riginal > source captures it might receive, it would enable correct spatial renderi= ng. > But as the number of captures per endpoint and the number of endpoints in > a conference rise caching all the data becomes impractical. > [CNG] I think the above are just a natural consequence that as the number= of > endpoints increase so will the amount of information that needs to be > signalled. I think the key point is that with the MCC concept the MCU has= to > choice to provide as much or as little information as it wants. It doesn'= t have > to pass on all the information that it receives in the source captures, i= t can > filter or manipulate the information as it sees fit. >=20 > With regards to the 2nd point the MCC concept allows the MCU to provide > "harmonised" spatial information regarding the MCC which means the a > Consumer could use this information rather than source spatial informatio= n if > conference size becomes a problem. > > > > I'm not sure what the practical limit on conference size would be. May= be > there are reasonable ways to do this in large conferences. This needs fu= rther > thought. > [CNG] I don't see that CLUE needs to place any limits on the conference s= ize. > I think its largely an endpoint decision on the amount of information it = wants > to provide. I think there are potential optimisation we can do in the cod= ing of > CLUE that will minimise the size of messages. For example introducing a > "range" concept to CSEs/MCCs/STSs that could allow to specify a group of > captures without specifying every one. >=20 > MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > Captures:1}{Policy1}{Encodinggroup1} > could be signalled as: > MCC100(VC4-VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} >=20 > Likewise a CSE for CaptureScene9 > CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12) > could be signalled as: > CSE(MCC4-MCC12) >=20 >=20 > > > > CapScene8 below is essentially the same idea as the "advertising multip= le > scenes" example in draft-duckworth-clue-switching-example-01, section 3.2= . > CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft. I ass= ume > CapScene8 would include spatial information for MCC1, MCC2, and MCC3. > And also I suggest CapScene8 could include other CSEs with fewer captures= , > such as: > > > MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > Captures:1}{Policy1}{Encodinggroup1} > > > MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > Captures:1}{Policy1}{Encodinggroup2} > > > MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max > Captures:1}{Policy1}{Encodinggroup1} > > CSE9(MCC100,MCC101) > > CSE10(MCC102) > > These CSEs would be useful for one or two screen consumers. > [CNG] Yes multiple Capture Scenes are used so this aspect parallels secti= on > 3.2 in your draft. Yes I agree that Capture8 could include CSEs with fewe= r > captures as you suggest. >=20 > > > > I have questions about how to use CapScene9 in the example below. > Would MCC4 through MCC12 have any spatial information? If so, what would > it be? Or does the consumer rely solely on the spatial information of VC= 4 > through VC15, along with some way of knowing which specific VC it is > receiving (within an MCC encoding) at any given time? > [CNG] Potentially MCC4 through MCC12 could have spatial information. An > advertiser could supply the same "virtual" capture area on each MCC > (i.e. a MCU may do some image processing to ensure they captures are the > same size) that way the consumer knows the MCCs are the same size. > Alternatively the MCC could change the location of the capture areas in > virtual space to suggest some sort of layout to a consumer. The 3rd > option is not to send spatial information. The above would be the > switching case. >=20 > In a composition case the Advertiser could provide a "harmonised" > virtual capture area on the MCC and it could provide capture area > information on the individual VCs to give their layout in the > "harmonised" capture area. >=20 >=20 > > > > Would CapScene9 also include other CSEs with fewer media captures in > them, indicating a consumer could choose fewer media captures and still g= et > a "representation of the whole scene" without receiving all 9 MCCs? > [CNG] CapScene9 could include CSEs with fewer captures. It would come > down to whether the Advertiser considers MCC4-MCC12 (or a subset of) as > representations of the overall scene or just as individual supplementary > streams. > > > > Regards, > > Mark > > > >> -----Original Message----- > >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] > >> Sent: Tuesday, September 17, 2013 11:16 PM > >> To: Duckworth, Mark; clue@ietf.org > >> Subject: Example of MCC > >> > >> Hello Mark, > >> > >> At yesterday's interim you asked if I could use the MCC concept > >> (draft-groves-clue-multi-content-00) to support the example in your dr= aft > ( > >> draft-duckworth-clue-switching-example-01). I assume that you were > talking > >> about the scenario in section 2. > >> > >> I think it is worthwhile to consider the "Endpoint" advertisements als= o. > >> From a CLUE perspective how an endpoint chooses to render the > received > >> encodings is largely irrelevant as it is up to the local policy. > >> > >> I would assume the source Advertisements would be something like: > >> > >> Endpoint A - 4 screens, 3 cameras > >> Endpoint B - 3 screens, 3 cameras > >> Endpoint C - 3 screens, 3 cameras > >> Endpoint D - 3 screens, 3 cameras > >> > >> Endpoints A-D: > >> CaptureScene1[Description=3DEndpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] > >> > >> Endpoints E-G: > >> CaptureScene1[Description=3DEndpoint y,VC1,CSE(VC1)] > >> > >> Note: The endpoints would be likely to use the same IDs in their > respective > >> Advertisements. > >> > >> Rather than considering what is displayed the MCC concepts concentrate= s > >> more on what the MCU/Mixer sends. The mixer doesn't know anything > >> about the number of screens an endpoint has. > >> > >> My assumption from the figures is that if the 3 main screens are "site= " > >> switching that there is one capture encoding/media stream for each. Th= e > >> MCU switches in the applicable media into the stream based on voice > activity > >> [policy1]. I assume endpoint A will not see a capture from itself. The > >> descriptions are just for information. > >> > >> Using the MCC concept the MCU would Advertise to endpoint A: > >> ----------------------------------------------------------- > >> > >> CapScene2[Description=3DEndpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] > >> > >> CapScene3[Description=3DEndpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] > >> > >> CapScene4[Description=3DEndpoint > >> D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] > >> > >> CapScene5[Description=3DEndpoint E,VC13,(CSE5(VC13)] > >> > >> CapScene6[Description=3DEndpoint F,VC14,(CSE6(VC13)] > >> > >> CapScene7[Description=3DEndpoint G,VC15,(CSE7(VC13)] > >> > >> // The above part effectively is the same as the input advertisements. > >> There are no capture encodings associated with them. > >> > >> CapScene8[Description=3DOutput3streammix, > >> MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} > >> {Encodinggroup1} > >> MCC2(VC5,VC8,VC11,VC13,VC14,VC15) > >> {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} > >> {Encodinggroup2} > >> MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} > >> {Encodinggroup3} > >> CSE8(MCC1,MCC2,MCC3) > >> > >> // The above part describes the switched 3 main streams that relate to > site > >> switching. MaxCaptures:1 indicates that only one capture from the MCC = is > >> sent at a particular time. The default if it wasn't included is 1 so i= t doesn't > >> need to be sent but included for clarity. Sync-id:1 indicates that the= source > >> sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15 > >> nothing will be sent in the other MCCs. > >> > >> CapScene9[Description=3DOutput9streams, > >> MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} > >> > >> MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} > >> > >> MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} > >> > >> MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} > >> > >> MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} > >> > >> MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} > >> > >> MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} > >> > >> MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} > >> > >> MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} > >> > >> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] > >> > >> // The above part indicates that there are 9 capture encodings. Each o= f > the > >> capture encodings may contain any captures from any source site with a > >> maximum of one capture at a time. Which capture is present is > determined > >> by Policy2. > >> > >> If the MCU wanted to provide a composed capture encoding of the 9 > >> captures it could Advertise in addition: > >> CapScene10[Description=3DNineTiles, > >> MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > >> VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} > >> CSE(MCC13) > >> // As maxcaptures is 9 it indicates that the capture encoding contains > >> information from up to 9 sources at a time. > >> > >> [CNG] The above arrangement allows a Consumer to understand how the > >> captures relate to the source sites. It means a Consumer can choose no= t > to > >> receive information from a particular source. This is not possible acc= ording > to > >> the "one big scene" approach below. > >> > >> The Advertisement for Endpoint B in your draft would be identical to t= he > >> above other than the captures from Endpoint A would be added and the > >> captures from Endpoint B would be removed. > >> > >> I hope this provides some clarification. > >> > >> Regards, Christian From christer.holmberg@ericsson.com Fri Sep 27 08:30:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2D9311E810A for ; Fri, 27 Sep 2013 08:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agIgPhWyd+BA for ; Fri, 27 Sep 2013 08:30:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 225E711E80D5 for ; Fri, 27 Sep 2013 08:30:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-3d-5245a483ae08 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9B.39.16099.384A5425; Fri, 27 Sep 2013 17:30:12 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 17:30:11 +0200 From: Christer Holmberg To: "Duckworth, Mark" , "clue@ietf.org" Thread-Topic: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQAE9KCQAAHo5wcAAH1AJw== Date: Fri, 27 Sep 2013 15:30:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4ADFB9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvrW7LEtcggzvPWS32n7rMbLHuyFNm ByaPJUt+Mnm8eKAUwBTFZZOSmpNZllqkb5fAldFzeSljwaRFjBXNc/uYGhhXdDF2MXJySAiY SLT1/mKGsMUkLtxbz9bFyMUhJHCYUeJky1t2CGcJo8SRvlMsXYwcHGwCFhLd/7RBGkQEQiVW z9zEAmILCyhIvH+xkxkirijx99sOdpByEYEsiUf/1UDCLAKqEqdnnmADsXkFfCVutbUwQoxv YZa4fGk3K0iCUyBA4tbzNrA5jEAHfT+1hgnEZhYQl7j1ZD4TxKECEkv2nIc6WlTi5eN/rBC2 osTOs+3MIHuZBfIlujrtIHYJSpyc+YRlAqPILCSTZiFUzUJSBVFiIPH+3HxmCFtbYtnC11C2 vsTGL2cZIWxriW3T9qGoWcDIsYqRPTcxMye93HATIzCiDm75rbuD8dQ5kUOM0hwsSuK8H946 BwkJpCeWpGanphakFsUXleakFh9iZOLglGpgnLGwkltZTy//2btVrrkd+/aemXYn+/Dhl+7H d0/ui3Q59TxSYIlt0gN90wXJ2/M5Mr3iWMUC7bhZAwT+rs5QuKAyn6vGasvMr12Tz7o2b5UQ 0Z71ny35qbnRhs+35l6TPnn8QAeDkEpD0NnNRYd45Yp2b9C7snzdux8BOdqXbitXP0x+8nXq biWW4oxEQy3mouJEAFZoDBx2AgAA Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 15:30:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4ADFB9ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mark, Se comments inline. The currently proposal works when the content of an MCC is one or more indi= vidual VCs, which the receiver can choose. That works fine when the MCU doe= s switching. But, in my opinion it does not work for composed MCCs, where the content of= the MCC can be built based on multiple Take an example: - in a conference, each site provides a CSE which contains two VCs: one wit= h main video, and one with slides/screen sharing. - the MCU wants to provide, at any given time, one of these CSEs (the selec= tion might be based on active speaker, or whatever) is a single stream towa= rds an endpoint. So, it advertises an "main-slide CSE from the site with th= e active speaker site" MCC. Now, I don't want the receiver to receive all the VCs, from the different s= ites, and try to figure out which belong toghether etc. And, the more VCs a= n CSE consist of, the more complicated it gets. [Duckworth, Mark] If the MCU does not want to advertise anything about the = other endpoint=92s VCs, then what is the point of using an MCC at all? In = this case, the MCU should simply advertise a composed VC. [Christer] Sure, the MCU could do that. However, there are more to sites than the VCs. For example, I may want to a= dvertise which sites are used to compose the MCC content. (however, CSE may= not be the best way to do that). Also, perhaps the MCU wants to advertise what type of video (e.g. main and = slide) the VC is composed of. I guess I could do something like MCC(MCC_Mai= n, MCC_Slide), or something like that... Regards, Christer Now, having said that, I DO agree that we should try to keep the "hiearchy"= . So, in this case, maybe we should introduce a Mixed CSE (MCSE) concept. The= MCU could then offer a "most active site" MCSE, in which it lists the MCC.= Something like: MCSE1(MCC1{Policy SceneWithTheActiveSpeaker}) Regards, Christer ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Christian = Groves [Christian.Groves@nteczone.com] Sent: Friday, 27 September 2013 3:57 AM To: clue@ietf.org Subject: Re: [clue] MCC with CSE Hello Christer, I had considered this issue when putting together the proposal and decided that a CSE should be in a MCC. The idea behind the MCC was that it was a capture. Captures go in CSEs not the other way around. As Mark mentioned using CSEs inside MCCs would lead to nesting issues i.e. CS,CSE,MCC,CSE. Also CSEs have a certain semantic that is that all the captures in the CSE make up one representation of a scene. It shouldn't be seen (pardon the pun) that CSEs is a syntax shorthand. I think there are other options for minimising message size. Regards, Christian On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > Hi, > > It's up to the advertiser to make sure it doesn't advertise things > that it can't provide. > > The MCU may request a specific CSE from an endpoint, and then > advertise that as a composed MCC to another endpoint. I don't see why > the MCU should have to advertise the VCs associated with that CSE, > when it can simply advertise the CSE. > > Regards, > > Christer > > ------------------------------------------------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces= @ietf.org] on behalf of > Duckworth, Mark [Mark.Duckworth@polycom.com] > *Sent:* Thursday, 26 September 2013 11:04 PM > *To:* CLUE > *Subject:* Re: [clue] MCC with CSE > > I think it would add complication and confusion to allow this. If > allowed, it would be just a shorthand for saying =93all the media > captures in this CSE can be included in this MCC=94. But it also opens > the door for nested MCCs (MCC includes a CSE that includes other > MCCs), which doesn=92t make sense to me, so I suggest we just avoid this > shorthand. > > Mark > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Christer Holmberg > *Sent:* Thursday, September 26, 2013 3:24 PM > *To:* CLUE > *Subject:* [clue] MCC with CSE > > Hi, > > There are some examples of CSEs which contain MCCs (e.g. > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > An example is when the MCC is composed of a whole capture scene entry. > > This is related to the discussion we previously had about simultaneous > sets, where I said that it should be possible to advertise, and > select, an CSE, rather than having to advertise and select each > individual capture within. > > Regards, > > Christer > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1C4ADFB9ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Mark,

 

Se comments inline.

 

 

The currently proposal works when the conten= t of an MCC is one or more individual VCs, which the receiver can choose. T= hat works fine when the MCU does switching.

 

But, in my opinion it does not work for comp= osed MCCs, where the content of the MCC can be built based on multiple

 

 

Take an example:

 

- in a conference, each site provides a CSE = which contains two VCs: one with main video, and one with slides/screen sha= ring.

 

- the MCU wants to provide, at any given tim= e, one of these CSEs (the selection might be based on active speaker, or wh= atever) is a single stream towards an endpoint. So, it advertises an "main-slide CSE from the site with the active speaker s= ite" MCC.

 

Now, I don't want the receiver to receive al= l the VCs, from the different sites, and try to figure out which belong tog= hether etc. And, the more VCs an CSE consist of, the more complicated it gets.

 

[Duckworth, Mark] If the M= CU does not want to advertise anything about the other endpoint=92s VCs, th= en what is the point of using an MCC at all?  In this case, the MCU should simply advertise a composed VC.

 

[C= hrister] Sure, the MCU could do that.

 

Ho= wever, there are more to sites than the VCs. For example, I may want to adv= ertise which sites are used to compose the MCC content. (however, CSE may not be the best way to do that).

 

Al= so, perhaps the MCU wants to advertise what type of video (e.g. main a= nd slide) the VC is composed of. I guess I could do something like MCC(MCC_Main, MCC_Slide), or something like that...=

 

Re= gards,

 

Ch= rister

 

 

Now, having said that, I DO agree that we sh= ould try to keep the "hiearchy".

 

So, in this case, maybe we should introduce = a Mixed CSE (MCSE) concept. The MCU could then offer a "most active si= te" MCSE, in which it lists the MCC. Something like: MCSE1(MCC1{Policy SceneWithTheActiveSpeaker})

 

Regards,

 

Christer

 

 

 

 

From: clue-bounces@ietf.or= g [clue-bounces@ietf.org] on behalf of Christian Groves [Christian.Groves@nteczone.com]
Sent: Friday, 27 September 2013 3:57 AM
To: clue@ietf.org
Subject: Re: [clue] MCC with CSE

Hello Christer,

I had considered this issue when putting together the proposal and
decided that a CSE should be in a MCC. The idea behind the MCC was that it was a capture. Captures go in CSEs not the other way around. As Mark mentioned using CSEs inside MCCs would lead to nesting issues i.e.
CS,CSE,MCC,CSE.

Also CSEs have a certain semantic that is that all the captures in the
CSE make up one representation of a scene. It shouldn't be seen (pardon the pun) that CSEs is a syntax shorthand. I think there are other
options for minimising message size.

Regards, Christian

On 27/09/2013 6:13 AM, Christer Holmberg wrote:
>
> Hi,
>
> It's up to the advertiser to make sure it doesn't advertise things > that it can't provide.
>
> The MCU may request a specific CSE from an endpoint, and then
> advertise that as a composed MCC to another endpoint. I don't see why =
> the MCU should have to advertise the VCs associated with that CSE, > when it can simply advertise the CSE.
>
> Regards,
>
> Christer
>
> ----------------------------------------------------------------------= --
> *From:* clu= e-bounces@ietf.org [clue-bounces@ietf.org] on behalf of
> Duckworth, Mark [Mark.Duckworth@polycom.com]
> *Sent:* Thursday, 26 September 2013 11:04 PM
> *To:* CLUE
> *Subject:* Re: [clue] MCC with CSE
>
> I think it would add complication and confusion to allow this. If
> allowed, it would be just a shorthand for saying =93all the media
> captures in this CSE can be included in this MCC=94. But it also opens=
> the door for nested MCCs (MCC includes a CSE that includes other
> MCCs), which doesn=92t make sense to me, so I suggest we just avoid th= is
> shorthand.
>
> Mark
>
> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf
> Of *Christer Holmberg
> *Sent:* Thursday, September 26, 2013 3:24 PM
> *To:* CLUE
> *Subject:* [clue] MCC with CSE
>
> Hi,
>
> There are some examples of CSEs which contain MCCs (e.g.
> CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to
> advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)).
>
> An example is when the MCC is composed of a whole capture scene entry.=
>
> This is related to the discussion we previously had about simultaneous=
> sets, where I said that it should be possible to advertise, and
> select, an CSE, rather than having to advertise and select each
> individual capture within.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue

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

--_000_7594FB04B1934943A5C02806D1A2204B1C4ADFB9ESESSMB209erics_-- From christer.holmberg@ericsson.com Fri Sep 27 09:38:02 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C577621E8104 for ; Fri, 27 Sep 2013 09:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.687 X-Spam-Level: X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EM3x3or-XQy for ; Fri, 27 Sep 2013 09:37:57 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 11FE821F9A61 for ; Fri, 27 Sep 2013 09:37:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-34-5245b45ecbd5 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 45.6D.16099.E54B5425; Fri, 27 Sep 2013 18:37:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 18:37:50 +0200 From: Christer Holmberg To: Christian Groves Thread-Topic: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? Thread-Index: Ac65T4XBVTijByKeQvuD6Q0zvuf0+f//6YAA//8WMOCAAfsNAP//0m9AgABbhICAA3dED////y0P Date: Fri, 27 Sep 2013 16:37:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4ADFFC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AB2A2@ESESSMB209.ericsson.se> <5241DBC4.9000506@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C4AB73E@ESESSMB209.ericsson.se> <5242C0FA.1010209@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ABC04@ESESSMB209.ericsson.se>, <5242E785.60103@nteczone.com> In-Reply-To: <5242E785.60103@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4ADFFCESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+JvrW78Ftcgg39/WSy+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJVx+MomxoIlGRVnNnxga2C8H9bFyMkhIWAi cXfGHGYIW0ziwr31bF2MXBxCAocZJeb9fw7lLGGUaH5/DqiKg4NNwEKi+582iCkC1Dz/rCZI L7OAssTXhk1MILawQILEtU2v2EFsEYFEiYnTGxkh7CiJ9fMusIDYLAKqEiuuHAGr5xXwlbh1 5DorxKrtTBKn964DK+IU0JL4cX862HGMQMd9P7WGCWKZuMStJ/OZII4WkFiy5zzUA6ISLx// Y4WwFSV2nm0HO5lZIF9i9u06iF2CEidnPmGZwCg6C8mkWQhVs5BUQZToSdyYOoUNwtaWWLbw NTOErSsx498hqBpriRvXFjAiq1nAyLGKkT03MTMnvdxwEyMwzg5u+a27g/HUOZFDjNIcLEri vB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJzQP0mtznRJn+OfkxManiyf4d/570nc k6cWrLKqkxaEPrss/+ndl3L90+2BZ/SSBD0P8sT8WCi3OLf9xTuJE4L517NXPGac1Trv6Nu7 xopmlwzi+X7ZsVdNnuc66+zSXz72My66rg1/lXs/YVmj0pxJV+q21QdpJzJ3uBw59VTxoWzD 5t2cPjOVWIozEg21mIuKEwGyJVolgQIAAA== Cc: "clue@ietf.org" Subject: Re: [clue] Does CLUE data channel failure implicitly trigger fallback to legacy mode? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 16:38:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4ADFFCESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, >>>>>> Without going into the details in this thread, "legacy mode" >>>>>> basically means communication between a CLUE entity and a non-CLUE e= ntity (read: >>>>>> an entity that does not support the CLUE protocol). >>>>>> >>>>>> In "CLUE mode", there is a data channel established for the exchange >>>>>> of CLUE protocol messages. >>>>>> >>>>>> One of the question has been whether a loss of that data channel >>>>>> means an automatic fallback to "legacy mode", or whether a fallback >>>>>> requires an explicit Offer, where the data channel is disabled etc. >>>>>> >>>>>> My opinion is that fallback to legacy DOES require an explicit >>>>>> Offer, e.g. for the following reasons: >>>>>> >>>>>> 1) Make sure that all parties are aware of the fallback. >>>>>> >>>>>> 2) There might be dedicated m=3Daudio/video lines for legacy mode, a= nd >>>>>> during clue mode they might be disabled. An Offer is needed in order >>>>>> to enable them. >>>>>> >>>>>> 3) Similar to 2), there are a number of dedicated m=3Daudio/video >>>>>> lines for clue mode, and when there is a fallback to legacy mode >>>>>> they need to be disabled (keeping them enabled might keep unecessary >>>>>> resources locked, and may also affect charging, etc). >>>>> I agree with all the above. >>>>> >>>>> It has been proposed by some that it might be desirable to close the = clue channel yet remain in CLUE mode. >>>>> >>>>> At least in principle this could work. The last negotiated >>>>> advertisement and configuration would remain in effect. I guess this = would save *some* (small) amount of resources in cases where no changes in = clue configuration are anticipated. >>>>> >>>>> If we did support this, then we would require an even more overt way = to indicate the transition to legacy mode. >>>>> >>>>> Personally I don't find this compelling. I'm satisfied with absence o= r explicit closing of the clue channel as the indicator for legacy mode. >>>>> But I think we need to get consensus on this. >>>> There may be a number of reason (some of which end users don't have an= y control over) why a the clue channel goes down, so my opinion is still th= at explicit closing (read: SDP Offer) is needed. >>>> >>>> Having said that, if the clue channel does go down, we probably need s= ome text on how to re-establish it. >>> [CNG] I think Paul is referring to me when he says "some". This was in = the context of what does it actually mean to the media if the >>> CLUE data channel is closed? If the CLUE data channel is closed it does= n't automatically mean that the media is removed or that the encoding >>> of the media changes. The media is only removed or changed via SDP. So = you can remove the CLUE data channel but the media established as a >>> result of a CLUE exchange remains. What do we assume about the metadata= (i.e. CLUE attributes) regarding those streams? i.e. is the spatial >>> information valid or no longer valid, etc? >> My idea is that, in legacy mode, we only have a single audio stream, two= video streams (of which one is for presentation/screen sharing), so there = is no need for spatial information. >> >> If you want to exchange spatial information - you use CLUE. >> > [CNG] I agree that if you want spatial information you use CLUE. I think > there's a difference in thinking of what legacy means. You seem to > assign a particular mode or configuration of streams. For me legacy is > with respect of the absence of CLUE rather than a particular media > configuration. An endpoint could have 5 video streams and still be > legacy if it doesn't understand CLUE. Sure, I don't think we want to forbid that. The whole idea of defining how the initial Offer looks like, is to make sur= e people know what they at least have to support in order to communicate wi= th a CLUE entity. But, in addition to that, you can of course negotiate as = many streams as you want. Regards, Christer > > >> Does the removal or the CLUE data channel only give a legacy state? or i= s the legacy mode reverting back to media that would have been established = in the absence of CLUE support? > In my opinion, there is no "that would have been established". In the rev= erting-back-to-legacy SDP Offer, you need to explicitly negotiate the media= you are going to use, the same way you do when you send the initial Offer = for the session. [CNG] Your definition of legacy above would fit my "that would have been established" description. If the endpoint didn't have CLUE it would have only used one audio and two video streams in the initial offer. > > Regards, > > Christer > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --_000_7594FB04B1934943A5C02806D1A2204B1C4ADFFCESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,

 

>>>>>&g= t; Without going into the details in this thread, "legacy mode" >>>>>> basically means communication between a CLUE entit= y and a non-CLUE entity (read:
>>>>>> an entity that does not support the CLUE protocol)= .
>>>>>>
>>>>>> In "CLUE mode", there is a data channel = established for the exchange
>>>>>> of CLUE protocol messages.
>>>>>>
>>>>>> One of the question has been whether a loss of tha= t data channel
>>>>>> means an automatic fallback to "legacy mode&q= uot;, or whether a fallback
>>>>>> requires an explicit Offer, where the data channel= is disabled etc.
>>>>>>
>>>>>> My opinion is that fallback to legacy DOES require= an explicit
>>>>>> Offer, e.g. for the following reasons:
>>>>>>
>>>>>> 1) Make sure that all parties are aware of the fal= lback.
>>>>>>
>>>>>> 2) There might be dedicated m=3Daudio/video lines = for legacy mode, and
>>>>>> during clue mode they might be disabled. An Offer = is needed in order
>>>>>> to enable them.
>>>>>>
>>>>>> 3) Similar to 2), there are a number of dedicated = m=3Daudio/video
>>>>>> lines for clue mode, and when there is a fallback = to legacy mode
>>>>>> they need to be disabled (keeping them enabled mig= ht keep unecessary
>>>>>> resources locked, and may also affect charging, et= c).
>>>>> I  agree with all the above.
>>>>>
>>>>> It has been proposed by some that it might be desirabl= e to close the clue channel yet remain in CLUE mode.
>>>>>
>>>>> At least in principle this could work. The last negoti= ated
>>>>> advertisement and configuration would remain in effect= . I guess this would save *some* (small) amount of resources in cases where= no changes in clue configuration are anticipated.
>>>>>
>>>>> If we did support this, then we would require an even = more overt way to indicate the transition to legacy mode.
>>>>>
>>>>> Personally I don't find this compelling. I'm satisfied= with absence or explicit closing of the clue channel as the indicator for = legacy mode.
>>>>> But I think we need to get consensus on this.
>>>> There may be a number of reason (some of which end users d= on't have any control over) why a the clue channel goes down, so my opinion= is still that explicit closing (read: SDP Offer) is needed.
>>>>
>>>> Having said that, if the clue channel does go down, we pro= bably need some text on how to re-establish it.
>>> [CNG] I think Paul is referring to me when he says "some&= quot;. This was in the context of what does it actually mean to the media i= f the
>>> CLUE data channel is closed? If the CLUE data channel is close= d it doesn't automatically mean that the media is removed or that the encod= ing
>>> of the media changes. The media is only removed or changed via= SDP. So you can remove the CLUE data channel but the media established as = a
>>> result of a CLUE exchange remains. What do we assume about the= metadata (i.e. CLUE attributes) regarding those streams? i.e. is the spati= al
>>> information valid or no longer valid, etc?
>> My idea is that, in legacy mode, we only have a single audio strea= m, two video streams (of which one is for presentation/screen sharing), so = there is no need for spatial information.
>>
>> If you want to exchange spatial information - you use CLUE.
>>

> [CNG] I agree tha= t if you want spatial information you use CLUE. I think
> there's a difference in thinking of what legacy means. You seem to > assign a particular mode or configuration of streams. For me legacy is=
> with respect of the absence of CLUE rather than a particular media > configuration. An endpoint could have 5 video streams and still be > legacy if it doesn't understand CLUE.

Sure, I don't think we= want to forbid that.

 

The whole idea of defi= ning how the initial Offer looks like, is to make sure people know what the= y at least have to support in order to communicate with a CLUE entity. But,= in addition to that, you can of course negotiate as many streams as you want.

 

Regards,=

 

Christer=

 

 

 

 

 

 


>  
>
>> Does the removal or the CLUE data channel only give a legacy state= ? or is the legacy mode reverting back to media that would have been establ= ished in the absence of CLUE support?
> In my opinion, there is no "that would have been established"= ;. In the reverting-back-to-legacy SDP Offer, you need to explicitly negoti= ate the media you are going to use, the same way you do when you send the i= nitial Offer for the session.
[CNG] Your definition of legacy above would fit my "that would have be= en
established" description. If the endpoint didn't have CLUE it would ha= ve
only used one audio and two video streams in the initial offer.

>
> Regards,
>
> Christer
>
>
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>

--_000_7594FB04B1934943A5C02806D1A2204B1C4ADFFCESESSMB209erics_-- From Christian.Groves@nteczone.com Fri Sep 27 14:42:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3977321F9F45 for ; Fri, 27 Sep 2013 14:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVCwg5ZoRPEq for ; Fri, 27 Sep 2013 14:42:17 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF9A21E8097 for ; Fri, 27 Sep 2013 14:42:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAEn6RVJ20XdP/2dsb2JhbAANToM/wRwJgTeDGQEBAQMBAQEBNRsVBgQGBgcECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYd8EqZykxoEjhOBRQaEGgOUIpkLgVYBBg Received: from ppp118-209-119-79.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.119.79]) by ipmail06.adl2.internode.on.net with ESMTP; 28 Sep 2013 07:12:10 +0930 Message-ID: <5245FBA5.6060809@nteczone.com> Date: Sat, 28 Sep 2013 07:41:57 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <52391AD2.5000701@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> <5244E2A7.8020601@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333E1FB@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60333E1FB@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 21:42:19 -0000 Hello Mark, Please see below. Regards, Christian On 28/09/2013 1:04 AM, Duckworth, Mark wrote: > Hi Christian, > > I agree the MCU provider can choose to provide as much or as little information as it wants. And I agree there could be optimizations to reduce CLUE message sizes. Given this, maybe it is enough to address the concerns about scaling to large conferences? What do others think? > > About CapScene9, I have more questions. You suggested the MCU could do some image processing to ensure captures are the same size, and indicate this by using the same virtual area of capture for each of the MCCs. I agree, but I was not too concerned about the relative sizes of the captures from different endpoints. I am more concerned about the spatial relationship between captures from the same endpoint in terms of how to order them next to each other for proper rendering. The consumer should have enough information to do this if the MCU provides all the original spatial information from each endpoint in the advertisement, do you agree? [CNG]Yes I agree. > > One downside to this approach is that every change the MCU makes in how it assigns contributing VCs to an MCC (e.g. make a switch based on current talker) could result in the consumer renderer needing to change how it maps decoder output to display locations. I need to think more about if this would really be a problem or not. [CNG] For this switching case I would think that a consumer would use the MCC spatial co-ordinate. i.e. in capturescene9 below MCC4 would always present the active speaker from the list of VC using the same co-ordinates. Or are you talking about switching the positions in a composed MCC? > In my example (section 3.2 of my draft) I attempted to address this by using multiple scenes, where each scene had fewer VCs (these could become MCCs) in each CSE, with some spatial information the MCU would adhere to when switching. I'm still leaning toward this multiple scene idea. I think combining it with the MCC concept will be an improvement. [CNG] I think the multiple scenes is the way to go. > > Still about CapScene9, you wrote "the MCC could change the location of the capture areas in virtual space to suggest some sort of layout to a consumer. The 3rd option is not to send spatial information." I don't understand what you mean, could you expand on this please? [CNG] The first part of the sentence refers to be capability to order them next to each other as you mention above. The 3rd option is to only send spatial information related to the MCC and not the VCs. In that case the consumer only knows the overall capture area of the MCC not the spatial area of the components. > > Regards, > Mark > >> -----Original Message----- >> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >> Sent: Thursday, September 26, 2013 9:43 PM >> To: Duckworth, Mark >> Cc: clue@ietf.org >> Subject: Re: Example of MCC >> >> Hello Mark, >> >> Please see my responses below. >> >> Regards, Christian >> >> On 27/09/2013 3:29 AM, Duckworth, Mark wrote: >>> Hello Christian, >>> >>> Thanks for the example, this is a good basis for discussion. >>> >>> One new key concept here is that CapScene2 through CapScene7 include >> media captures that are not associated with any encoding group. This >> indicates the consumer cannot ask for these captures directly in a configure >> message, because there is no way for the consumer to ask for a capture >> encoding of any of these captures directly. I have considered this idea >> before, and it does seem useful. This MCC example is taking this approach >> with the MCU advertising all the other endpoints' captures, to give >> information about them, but not for directly putting into capture encodings >> sent from the MCU. >> [CNG] Yes that's correct. >>> However, there could be issues in scaling to large conferences. Here are >> two points from draft-duckworth-clue-switching-example-01 (originally from >> draft-hansen-clue-consumer-layout): >>> 1. The mixer could advertise all the other endpoint's captures, but as the >> size of the conference increases the number of captures that must be >> advertised will quickly become impractical. >>> 2. If the renderer had all the spatial information about all possible original >> source captures it might receive, it would enable correct spatial rendering. >> But as the number of captures per endpoint and the number of endpoints in >> a conference rise caching all the data becomes impractical. >> [CNG] I think the above are just a natural consequence that as the number of >> endpoints increase so will the amount of information that needs to be >> signalled. I think the key point is that with the MCC concept the MCU has to >> choice to provide as much or as little information as it wants. It doesn't have >> to pass on all the information that it receives in the source captures, it can >> filter or manipulate the information as it sees fit. >> >> With regards to the 2nd point the MCC concept allows the MCU to provide >> "harmonised" spatial information regarding the MCC which means the a >> Consumer could use this information rather than source spatial information if >> conference size becomes a problem. >>> I'm not sure what the practical limit on conference size would be. Maybe >> there are reasonable ways to do this in large conferences. This needs further >> thought. >> [CNG] I don't see that CLUE needs to place any limits on the conference size. >> I think its largely an endpoint decision on the amount of information it wants >> to provide. I think there are potential optimisation we can do in the coding of >> CLUE that will minimise the size of messages. For example introducing a >> "range" concept to CSEs/MCCs/STSs that could allow to specify a group of >> captures without specifying every one. >> >> MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >> Captures:1}{Policy1}{Encodinggroup1} >> could be signalled as: >> MCC100(VC4-VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} >> >> Likewise a CSE for CaptureScene9 >> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12) >> could be signalled as: >> CSE(MCC4-MCC12) >> >> >>> CapScene8 below is essentially the same idea as the "advertising multiple >> scenes" example in draft-duckworth-clue-switching-example-01, section 3.2. >> CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft. I assume >> CapScene8 would include spatial information for MCC1, MCC2, and MCC3. >> And also I suggest CapScene8 could include other CSEs with fewer captures, >> such as: >> MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >> Captures:1}{Policy1}{Encodinggroup1} >> MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >> Captures:1}{Policy1}{Encodinggroup2} >> MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >> Captures:1}{Policy1}{Encodinggroup1} >>> CSE9(MCC100,MCC101) >>> CSE10(MCC102) >>> These CSEs would be useful for one or two screen consumers. >> [CNG] Yes multiple Capture Scenes are used so this aspect parallels section >> 3.2 in your draft. Yes I agree that Capture8 could include CSEs with fewer >> captures as you suggest. >> >>> I have questions about how to use CapScene9 in the example below. >> Would MCC4 through MCC12 have any spatial information? If so, what would >> it be? Or does the consumer rely solely on the spatial information of VC4 >> through VC15, along with some way of knowing which specific VC it is >> receiving (within an MCC encoding) at any given time? >> [CNG] Potentially MCC4 through MCC12 could have spatial information. An >> advertiser could supply the same "virtual" capture area on each MCC >> (i.e. a MCU may do some image processing to ensure they captures are the >> same size) that way the consumer knows the MCCs are the same size. >> Alternatively the MCC could change the location of the capture areas in >> virtual space to suggest some sort of layout to a consumer. The 3rd >> option is not to send spatial information. The above would be the >> switching case. >> >> In a composition case the Advertiser could provide a "harmonised" >> virtual capture area on the MCC and it could provide capture area >> information on the individual VCs to give their layout in the >> "harmonised" capture area. >> >> >>> Would CapScene9 also include other CSEs with fewer media captures in >> them, indicating a consumer could choose fewer media captures and still get >> a "representation of the whole scene" without receiving all 9 MCCs? >> [CNG] CapScene9 could include CSEs with fewer captures. It would come >> down to whether the Advertiser considers MCC4-MCC12 (or a subset of) as >> representations of the overall scene or just as individual supplementary >> streams. >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>> Sent: Tuesday, September 17, 2013 11:16 PM >>>> To: Duckworth, Mark; clue@ietf.org >>>> Subject: Example of MCC >>>> >>>> Hello Mark, >>>> >>>> At yesterday's interim you asked if I could use the MCC concept >>>> (draft-groves-clue-multi-content-00) to support the example in your draft >> ( >>>> draft-duckworth-clue-switching-example-01). I assume that you were >> talking >>>> about the scenario in section 2. >>>> >>>> I think it is worthwhile to consider the "Endpoint" advertisements also. >>>> From a CLUE perspective how an endpoint chooses to render the >> received >>>> encodings is largely irrelevant as it is up to the local policy. >>>> >>>> I would assume the source Advertisements would be something like: >>>> >>>> Endpoint A - 4 screens, 3 cameras >>>> Endpoint B - 3 screens, 3 cameras >>>> Endpoint C - 3 screens, 3 cameras >>>> Endpoint D - 3 screens, 3 cameras >>>> >>>> Endpoints A-D: >>>> CaptureScene1[Description=Endpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] >>>> >>>> Endpoints E-G: >>>> CaptureScene1[Description=Endpoint y,VC1,CSE(VC1)] >>>> >>>> Note: The endpoints would be likely to use the same IDs in their >> respective >>>> Advertisements. >>>> >>>> Rather than considering what is displayed the MCC concepts concentrates >>>> more on what the MCU/Mixer sends. The mixer doesn't know anything >>>> about the number of screens an endpoint has. >>>> >>>> My assumption from the figures is that if the 3 main screens are "site" >>>> switching that there is one capture encoding/media stream for each. The >>>> MCU switches in the applicable media into the stream based on voice >> activity >>>> [policy1]. I assume endpoint A will not see a capture from itself. The >>>> descriptions are just for information. >>>> >>>> Using the MCC concept the MCU would Advertise to endpoint A: >>>> ----------------------------------------------------------- >>>> >>>> CapScene2[Description=Endpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] >>>> >>>> CapScene3[Description=Endpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] >>>> >>>> CapScene4[Description=Endpoint >>>> D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] >>>> >>>> CapScene5[Description=Endpoint E,VC13,(CSE5(VC13)] >>>> >>>> CapScene6[Description=Endpoint F,VC14,(CSE6(VC13)] >>>> >>>> CapScene7[Description=Endpoint G,VC15,(CSE7(VC13)] >>>> >>>> // The above part effectively is the same as the input advertisements. >>>> There are no capture encodings associated with them. >>>> >>>> CapScene8[Description=Output3streammix, >>>> MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} >>>> {Encodinggroup1} >>>> MCC2(VC5,VC8,VC11,VC13,VC14,VC15) >>>> {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} >>>> {Encodinggroup2} >>>> MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} >>>> {Encodinggroup3} >>>> CSE8(MCC1,MCC2,MCC3) >>>> >>>> // The above part describes the switched 3 main streams that relate to >> site >>>> switching. MaxCaptures:1 indicates that only one capture from the MCC is >>>> sent at a particular time. The default if it wasn't included is 1 so it doesn't >>>> need to be sent but included for clarity. Sync-id:1 indicates that the source >>>> sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15 >>>> nothing will be sent in the other MCCs. >>>> >>>> CapScene9[Description=Output9streams, >>>> MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} >>>> >>>> MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} >>>> >>>> MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} >>>> >>>> MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} >>>> >>>> MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} >>>> >>>> MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} >>>> >>>> MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} >>>> >>>> MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} >>>> >>>> MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} >>>> >>>> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] >>>> >>>> // The above part indicates that there are 9 capture encodings. Each of >> the >>>> capture encodings may contain any captures from any source site with a >>>> maximum of one capture at a time. Which capture is present is >> determined >>>> by Policy2. >>>> >>>> If the MCU wanted to provide a composed capture encoding of the 9 >>>> captures it could Advertise in addition: >>>> CapScene10[Description=NineTiles, >>>> MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>> VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} >>>> CSE(MCC13) >>>> // As maxcaptures is 9 it indicates that the capture encoding contains >>>> information from up to 9 sources at a time. >>>> >>>> [CNG] The above arrangement allows a Consumer to understand how the >>>> captures relate to the source sites. It means a Consumer can choose not >> to >>>> receive information from a particular source. This is not possible according >> to >>>> the "one big scene" approach below. >>>> >>>> The Advertisement for Endpoint B in your draft would be identical to the >>>> above other than the captures from Endpoint A would be added and the >>>> captures from Endpoint B would be removed. >>>> >>>> I hope this provides some clarification. >>>> >>>> Regards, Christian > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Fri Sep 27 14:53:59 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C18721F92E7 for ; Fri, 27 Sep 2013 14:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh3ByiyX9PLM for ; Fri, 27 Sep 2013 14:53:58 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id DA69721F9AA4 for ; Fri, 27 Sep 2013 14:53:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBANz9RVJ20XdP/2dsb2JhbAANToM/wSWBN4MZAQEBBAEBAS8BBRsVBgoRCxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYgOpniTGQSPWAaEGgOtLQ Received: from ppp118-209-119-79.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.119.79]) by ipmail06.adl2.internode.on.net with ESMTP; 28 Sep 2013 07:23:56 +0930 Message-ID: <5245FE6A.5080704@nteczone.com> Date: Sat, 28 Sep 2013 07:53:46 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 21:53:59 -0000 Hello Christer, I had the same reaction as Mark, if the consumer doesn't want to know about the sources then the MCU could simply just advertise a VC (main, slide) to represent the single stream from each site. A minimal implementation for switching could just specify MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker. This would say the capture is a switched capture showing one capture at a time based on who is the active speaker, that is main and slides. If you did want the whole source information in this case you are doing composition and switching so multiple MCCs would be needed. E.g. CaptureScene1 VC1(Main),VC2(Slides) MCC1(VC1,VC2,Maxcaptures=2(i.e. composed) CaptureScene2 VC3(Main),VC4(Slides) MCC2(VC3,VC4,Maxcaptures=2(i.e. composed) CaptureScene3 MCC3(MCC1,MCC2,MaxCaptures=1 (i.e. switched),Policy=active speaker),encodinggroup Regards, Christian On 28/09/2013 1:30 AM, Christer Holmberg wrote: > > Hi Mark, > > Se comments inline. > > The currently proposal works when the content of an MCC is one or more > individual VCs, which the receiver can choose. That works fine when > the MCU does switching. > > But, in my opinion it does not work for composed MCCs, where the > content of the MCC can be built based on multiple > > Take an example: > > - in a conference, each site provides a CSE which contains two VCs: > one with main video, and one with slides/screen sharing. > > - the MCU wants to provide, at any given time, one of these CSEs (the > selection might be based on active speaker, or whatever) is a single > stream towards an endpoint. So, it advertises an "main-slide CSE from > the site with the active speaker site" MCC. > > Now, I don't want the receiver to receive all the VCs, from the > different sites, and try to figure out which belong toghether etc. > And, the more VCs an CSE consist of, the more complicated it gets. > > *//* > > */[Duckworth, Mark] If the MCU does not want to advertise anything > about the other endpoint’s VCs, then what is the point of using an MCC > at all? In this case, the MCU should simply advertise a composed VC./* > > *//* > > */[Christer] Sure, the MCU could do that. /* > > *//* > > */However, there are more to sites than the VCs. For example, I may > want to advertise which sites are used to compose the MCC content. > (however, CSE may not be the best way to do that)./* > > *//* > > */Also, perhaps the MCU wants to advertise what type of video (e.g. > main and slide) the VC is composed of. I guess I could do something > like MCC(MCC_Main, MCC_Slide), or something like that.../* > > *//* > > */Regards,/* > > *//* > > */Christer/* > > *//* > > Now, having said that, I DO agree that we should try to keep the > "hiearchy". > > So, in this case, maybe we should introduce a Mixed CSE (MCSE) > concept. The MCU could then offer a "most active site" MCSE, in which > it lists the MCC. Something like: MCSE1(MCC1{Policy > SceneWithTheActiveSpeaker}) > > Regards, > > Christer > > ------------------------------------------------------------------------ > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > Christian Groves [Christian.Groves@nteczone.com] > *Sent:* Friday, 27 September 2013 3:57 AM > *To:* clue@ietf.org > *Subject:* Re: [clue] MCC with CSE > > Hello Christer, > > I had considered this issue when putting together the proposal and > decided that a CSE should be in a MCC. The idea behind the MCC was that > it was a capture. Captures go in CSEs not the other way around. As Mark > mentioned using CSEs inside MCCs would lead to nesting issues i.e. > CS,CSE,MCC,CSE. > > Also CSEs have a certain semantic that is that all the captures in the > CSE make up one representation of a scene. It shouldn't be seen (pardon > the pun) that CSEs is a syntax shorthand. I think there are other > options for minimising message size. > > Regards, Christian > > On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > > > Hi, > > > > It's up to the advertiser to make sure it doesn't advertise things > > that it can't provide. > > > > The MCU may request a specific CSE from an endpoint, and then > > advertise that as a composed MCC to another endpoint. I don't see why > > the MCU should have to advertise the VCs associated with that CSE, > > when it can simply advertise the CSE. > > > > Regards, > > > > Christer > > > > ------------------------------------------------------------------------ > > *From:* clue-bounces@ietf.org > [clue-bounces@ietf.org] on behalf of > > Duckworth, Mark [Mark.Duckworth@polycom.com] > > *Sent:* Thursday, 26 September 2013 11:04 PM > > *To:* CLUE > > *Subject:* Re: [clue] MCC with CSE > > > > I think it would add complication and confusion to allow this. If > > allowed, it would be just a shorthand for saying “all the media > > captures in this CSE can be included in this MCC”. But it also opens > > the door for nested MCCs (MCC includes a CSE that includes other > > MCCs), which doesn’t make sense to me, so I suggest we just avoid this > > shorthand. > > > > Mark > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > > Of *Christer Holmberg > > *Sent:* Thursday, September 26, 2013 3:24 PM > > *To:* CLUE > > *Subject:* [clue] MCC with CSE > > > > Hi, > > > > There are some examples of CSEs which contain MCCs (e.g. > > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > > > An example is when the MCC is composed of a whole capture scene entry. > > > > This is related to the discussion we previously had about simultaneous > > sets, where I said that it should be possible to advertise, and > > select, an CSE, rather than having to advertise and select each > > individual capture within. > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From christer.holmberg@ericsson.com Sat Sep 28 04:57:49 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0CA11E80E2 for ; Sat, 28 Sep 2013 04:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.384 X-Spam-Level: X-Spam-Status: No, score=-5.384 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6j1gxUN8VlR for ; Sat, 28 Sep 2013 04:57:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id F155F21F9A19 for ; Sat, 28 Sep 2013 04:57:19 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-d9-5246c41b80e3 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 27.FD.22048.B14C6425; Sat, 28 Sep 2013 13:57:15 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Sat, 28 Sep 2013 13:57:14 +0200 From: Christer Holmberg To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] MCC with CSE Thread-Index: Ac667e+wejUAl2zkQiKqe4+0SWiBlQABUzJgAABBN9oAACcP9wAFtesAABrdwjoAAHd3TQAE9KCQAAHo5wcAAH1AJwAJNF4AACGL5eAAABqrHg== Date: Sat, 28 Sep 2013 11:57:14 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> In-Reply-To: <5245FE6A.5080704@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AEA35ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyM+Jvra70Ebcgg21/hC2+vG9ksdh/6jKz A5PHkiU/mTxWnJ/JEsAUxWWTkpqTWZZapG+XwJXR+uwqa8GxTsaKG4+OsjcwHirsYuTkkBAw kbj59wIjhC0mceHeerYuRi4OIYHDjBJHJk1ignCWMEosaJ4P5HBwsAlYSHT/0wZpEBEIl+jY dgWsWVhAQeL9i53MEHFFib/fdrBD2HUSTY0TwOIsAqoSt+4vAavnFfCVmLryB9SyV8wSX+7d YQVJcAroSFzb/ZUJxGYEuuj7qTVgNrOAuMStJ/OZIC4VkFiy5zwzhC0q8fLxP1YIW1Hi46t9 jBD1+RKtCyawQSwTlDg58wnLBEaRWUhGzUJSNgtJGUTcQOL9ufnMELa2xLKFr6FsfYmNX84y zgIGBbOAtcTjtRLIShYwcqxiZM9NzMxJLzffxAiMqoNbfhvsYNx0X+wQozQHi5I474e3zkFC AumJJanZqakFqUXxRaU5qcWHGJk4OKUaGFuYzt++VP11Q/hMM6/bcdMuWeWtWTKxLZzxU8g2 OfPeLTpef1XPLm/PVDy+/p3BnZ+ti1l/zU34bJfr4LR0Q0bgssa04q4PvT+eL3NS3i8qvJhp 3ZETEfKXJqkX5pyZc+6KfNCnZ6wXZ+Xs4Xe31ZeK/BFeIWzu3fxtwm2+DWynPx8sTrmqeUiJ pTgj0VCLuag4EQCs61C9eAIAAA== Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2013 11:57:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AEA35ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >I had the same reaction as Mark, if the consumer doesn't want to know >about the sources then the MCU could simply just advertise a VC (main, >slide) to represent the single stream from each site. > >A minimal implementation for switching could just specify >MCC():MaxCaptures=3D1,Attribute(Main,slide),Policy=3Dactivespeaker. This >would say the capture is a switched capture showing one capture at a >time based on who is the active speaker, that is main and slides. Correct. >If you did want the whole source information in this case you are doing >composition and switching so multiple MCCs would be needed. > >E.g. CaptureScene1 VC1(Main),VC2(Slides) >MCC1(VC1,VC2,Maxcaptures=3D2(i.e. composed) >CaptureScene2 VC3(Main),VC4(Slides) >MCC2(VC3,VC4,Maxcaptures=3D2(i.e. composed) >CaptureScene3 MCC3(MCC1,MCC2,MaxCaptures=3D1 (i.e. switched),Policy=3Dacti= ve >speaker),encodinggroup I don't necessarily want the source information. But, I may want to know e.= g. which sites are used to compose the MCC content. But, maybe such "metada= ta" can be provided using some composed attribute, or something? Also, I assume that an MCC doesn't necessarily have to be generated by an M= CU. An endpoint could also advertise an MCC, e.g. the one in my example wit= h main and slide. Regards, Christer On 28/09/2013 1:30 AM, Christer Holmberg wrote: > > Hi Mark, > > Se comments inline. > > The currently proposal works when the content of an MCC is one or more > individual VCs, which the receiver can choose. That works fine when > the MCU does switching. > > But, in my opinion it does not work for composed MCCs, where the > content of the MCC can be built based on multiple > > Take an example: > > - in a conference, each site provides a CSE which contains two VCs: > one with main video, and one with slides/screen sharing. > > - the MCU wants to provide, at any given time, one of these CSEs (the > selection might be based on active speaker, or whatever) is a single > stream towards an endpoint. So, it advertises an "main-slide CSE from > the site with the active speaker site" MCC. > > Now, I don't want the receiver to receive all the VCs, from the > different sites, and try to figure out which belong toghether etc. > And, the more VCs an CSE consist of, the more complicated it gets. > > *//* > > */[Duckworth, Mark] If the MCU does not want to advertise anything > about the other endpoint=92s VCs, then what is the point of using an MCC > at all? In this case, the MCU should simply advertise a composed VC./* > > *//* > > */[Christer] Sure, the MCU could do that. /* > > *//* > > */However, there are more to sites than the VCs. For example, I may > want to advertise which sites are used to compose the MCC content. > (however, CSE may not be the best way to do that)./* > > *//* > > */Also, perhaps the MCU wants to advertise what type of video (e.g. > main and slide) the VC is composed of. I guess I could do something > like MCC(MCC_Main, MCC_Slide), or something like that.../* > > *//* > > */Regards,/* > > *//* > > */Christer/* > > *//* > > Now, having said that, I DO agree that we should try to keep the > "hiearchy". > > So, in this case, maybe we should introduce a Mixed CSE (MCSE) > concept. The MCU could then offer a "most active site" MCSE, in which > it lists the MCC. Something like: MCSE1(MCC1{Policy > SceneWithTheActiveSpeaker}) > > Regards, > > Christer > > ------------------------------------------------------------------------ > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > Christian Groves [Christian.Groves@nteczone.com] > *Sent:* Friday, 27 September 2013 3:57 AM > *To:* clue@ietf.org > *Subject:* Re: [clue] MCC with CSE > > Hello Christer, > > I had considered this issue when putting together the proposal and > decided that a CSE should be in a MCC. The idea behind the MCC was that > it was a capture. Captures go in CSEs not the other way around. As Mark > mentioned using CSEs inside MCCs would lead to nesting issues i.e. > CS,CSE,MCC,CSE. > > Also CSEs have a certain semantic that is that all the captures in the > CSE make up one representation of a scene. It shouldn't be seen (pardon > the pun) that CSEs is a syntax shorthand. I think there are other > options for minimising message size. > > Regards, Christian > > On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > > > Hi, > > > > It's up to the advertiser to make sure it doesn't advertise things > > that it can't provide. > > > > The MCU may request a specific CSE from an endpoint, and then > > advertise that as a composed MCC to another endpoint. I don't see why > > the MCU should have to advertise the VCs associated with that CSE, > > when it can simply advertise the CSE. > > > > Regards, > > > > Christer > > > > -----------------------------------------------------------------------= - > > *From:* clue-bounces@ietf.org > [clue-bounces@ietf.org] on behalf of > > Duckworth, Mark [Mark.Duckworth@polycom.com] > > *Sent:* Thursday, 26 September 2013 11:04 PM > > *To:* CLUE > > *Subject:* Re: [clue] MCC with CSE > > > > I think it would add complication and confusion to allow this. If > > allowed, it would be just a shorthand for saying =93all the media > > captures in this CSE can be included in this MCC=94. But it also opens > > the door for nested MCCs (MCC includes a CSE that includes other > > MCCs), which doesn=92t make sense to me, so I suggest we just avoid thi= s > > shorthand. > > > > Mark > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > > Of *Christer Holmberg > > *Sent:* Thursday, September 26, 2013 3:24 PM > > *To:* CLUE > > *Subject:* [clue] MCC with CSE > > > > Hi, > > > > There are some examples of CSEs which contain MCCs (e.g. > > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > > > An example is when the MCC is composed of a whole capture scene entry. > > > > This is related to the discussion we previously had about simultaneous > > sets, where I said that it should be possible to advertise, and > > select, an CSE, rather than having to advertise and select each > > individual capture within. > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_7594FB04B1934943A5C02806D1A2204B1C4AEA35ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi,


>I had the same reaction as Mark, if the consumer doesn't want to know <= br> >about the sources then the MCU could simply just advertise a VC (main, =
>slide) to represent the single stream from each site.
>
>A minimal implementation for switching could just specify
>MCC():MaxCaptures=3D1,Attribute(Main,slide),Policy=3Dactivespeaker. Thi= s
>would say the capture is a switched capture showing one capture at a >time based on who is the active speaker, that is main and slides.

 

Correct.


>If you did want the whole source information in this case you are doing=
>composition and switching so multiple MCCs would be needed.
>
>E.g. CaptureScene1 VC1(Main),VC2(Slides)
>MCC1(VC1,VC2,Maxcaptures=3D2(i.e. composed)
>CaptureScene2 VC3(Main),VC4(Slides)
>MCC2(VC3,VC4,Maxcaptures=3D2(i.e. composed)
>CaptureScene3 MCC3(MCC1,MCC2,MaxCaptures=3D1 (i.e. switched),Policy=3Da= ctive
>speaker),encodinggroup

 

I don't necessarily want the source information. But, I may want to know= e.g. which sites are used to compose the MCC content. But, maybe such &quo= t;metadata" can be provided using some composed attribute, or somethin= g?

 

Also, I assume that an MCC doesn't necessarily have to be generated by a= n MCU. An endpoint could also advertise an MCC, e.g. the one in my example = with main and slide.

 

Regards,

 

Christer




On 28/09/2013 1:30 AM, Christer Holmberg wrote:
>
> Hi Mark,
>
> Se comments inline.
>
> The currently proposal works when the content of an MCC is one or more=
> individual VCs, which the receiver can choose. That works fine when > the MCU does switching.
>
> But, in my opinion it does not work for composed MCCs, where the
> content of the MCC can be built based on multiple
>
> Take an example:
>
> - in a conference, each site provides a CSE which contains two VCs: > one with main video, and one with slides/screen sharing.
>
> - the MCU wants to provide, at any given time, one of these CSEs (the =
> selection might be based on active speaker, or whatever) is a single <= br> > stream towards an endpoint. So, it advertises an "main-slide CSE = from
> the site with the active speaker site" MCC.
>
> Now, I don't want the receiver to receive all the VCs, from the
> different sites, and try to figure out which belong toghether etc. > And, the more VCs an CSE consist of, the more complicated it gets.
>
> *//*
>
> */[Duckworth, Mark] If the MCU does not want to advertise anything > about the other endpoint=92s VCs, then what is the point of using an M= CC
> at all? In this case, the MCU should simply advertise a composed VC./*=
>
> *//*
>
> */[Christer] Sure, the MCU could do that. /*
>
> *//*
>
> */However, there are more to sites than the VCs. For example, I may > want to advertise which sites are used to compose the MCC content. > (however, CSE may not be the best way to do that)./*
>
> *//*
>
> */Also, perhaps the MCU wants to advertise what type of video (e.g. > main and slide) the VC is composed of. I guess I could do something > like MCC(MCC_Main, MCC_Slide), or something like that.../*
>
> *//*
>
> */Regards,/*
>
> *//*
>
> */Christer/*
>
> *//*
>
> Now, having said that, I DO agree that we should try to keep the
> "hiearchy".
>
> So, in this case, maybe we should introduce a Mixed CSE (MCSE)
> concept. The MCU could then offer a "most active site" MCSE,= in which
> it lists the MCC. Something like: MCSE1(MCC1{Policy
> SceneWithTheActiveSpeaker})
>
> Regards,
>
> Christer
>
> ----------------------------------------------------------------------= --
>
> *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of
> Christian Groves [Christian.Groves@nteczone.com]
> *Sent:* Friday, 27 September 2013 3:57 AM
> *To:* clue@ietf.org
> *Subject:* Re: [clue] MCC with CSE
>
> Hello Christer,
>
> I had considered this issue when putting together the proposal and
> decided that a CSE should be in a MCC. The idea behind the MCC was tha= t
> it was a capture. Captures go in CSEs not the other way around. As Mar= k
> mentioned using CSEs inside MCCs would lead to nesting issues i.e.
> CS,CSE,MCC,CSE.
>
> Also CSEs have a certain semantic that is that all the captures in the=
> CSE make up one representation of a scene. It shouldn't be seen (pardo= n
> the pun) that CSEs is a syntax shorthand. I think there are other
> options for minimising message size.
>
> Regards, Christian
>
> On 27/09/2013 6:13 AM, Christer Holmberg wrote:
> >
> > Hi,
> >
> > It's up to the advertiser to make sure it doesn't advertise thing= s
> > that it can't provide.
> >
> > The MCU may request a specific CSE from an endpoint, and then
> > advertise that as a composed MCC to another endpoint. I don't see= why
> > the MCU should have to advertise the VCs associated with that CSE= ,
> > when it can simply advertise the CSE.
> >
> > Regards,
> >
> > Christer
> >
> > -----------------------------------------------------------------= -------
> > *From:* clue-bounces@ietf.org <mailto:clue-bounces@ietf.org>
> [clue-bounces@ietf.org] on behalf of
> > Duckworth, Mark [Mark.Duckworth@polycom.com]
> > *Sent:* Thursday, 26 September 2013 11:04 PM
> > *To:* CLUE
> > *Subject:* Re: [clue] MCC with CSE
> >
> > I think it would add complication and confusion to allow this. If=
> > allowed, it would be just a shorthand for saying =93all the media=
> > captures in this CSE can be included in this MCC=94. But it also = opens
> > the door for nested MCCs (MCC includes a CSE that includes other<= br> > > MCCs), which doesn=92t make sense to me, so I suggest we just avo= id this
> > shorthand.
> >
> > Mark
> >
> > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf
> > Of *Christer Holmberg
> > *Sent:* Thursday, September 26, 2013 3:24 PM
> > *To:* CLUE
> > *Subject:* [clue] MCC with CSE
> >
> > Hi,
> >
> > There are some examples of CSEs which contain MCCs (e.g.
> > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)).
> >
> > An example is when the MCC is composed of a whole capture scene e= ntry.
> >
> > This is related to the discussion we previously had about simulta= neous
> > sets, where I said that it should be possible to advertise, and > > select, an CSE, rather than having to advertise and select each > > individual capture within.
> >
> > Regards,
> >
> > Christer
> >
> >
> >
> > _______________________________________________
> > clue mailing list
> > clue@ietf.org <mailto:clue@ietf.org>
> > https://www.ietf.org/mailman/listinfo/clue
>
> _______________________________________________
> clue mailing list
> clue@ietf.org <m= ailto:clue@ietf.org>
> https://www.ietf.org/mailman/listinfo/clue
>
>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

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

--_000_7594FB04B1934943A5C02806D1A2204B1C4AEA35ESESSMB209erics_-- From keith.drage@alcatel-lucent.com Sat Sep 28 12:05:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBB221E80F0 for ; Sat, 28 Sep 2013 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3DIpaSFXkPm for ; Sat, 28 Sep 2013 12:05:20 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFDC21E80EB for ; Sat, 28 Sep 2013 12:05:16 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r8SJ53cH013159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 28 Sep 2013 14:05:05 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r8SJ50K2001319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 28 Sep 2013 21:05:01 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sat, 28 Sep 2013 21:05:00 +0200 From: "DRAGE, Keith (Keith)" To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Is 2nd most active speaker a role? Thread-Index: AQHOucJdl4HLcnqYQhawTx6bwHJDQpnbh6tw Date: Sat, 28 Sep 2013 19:04:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B0ABFE1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B1C4AB149@ESESSMB209.ericsson.se> <5241B412.6050507@stpeter.im> <5241DDC7.5020608@alum.mit.edu> <52429331.1090909@nteczone.com> In-Reply-To: <52429331.1090909@nteczone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [clue] Is 2nd most active speaker a role? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 19:05:26 -0000 This appears to me to be the correct direction. Keith > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Christian Groves > Sent: 25 September 2013 08:39 > To: clue@ietf.org > Subject: Re: [clue] Is 2nd most active speaker a role? >=20 > Hello Christer, >=20 > I don't think "most active, second most active, etc" really fit what > roles are about. To me they're more related to switching and switching > policy. To me they seem to be an attribute related to a switched > capture. I.e. the capture is switched to always show the most active > speaker, etc. >=20 > This fits with what I have been trying to do with my multiple content > capture draft. >=20 > Using the example of MCC that I previously posted to the list, a > possible implementation could be: > CapScene9[Description=3DOutput9streams, > MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy=3Dmost_active_speaker}{Encodinggroup4} >=20 > MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, > VC14,VC15){MaxCaptures:1}{Policy=3D2nd_active_speaker}{Encodinggroup5} >=20 > etc. >=20 > This would indicate that MCC4 would contain the most active speaker from > source captures VC4 to VC15 and MCC5 would contain the 2nd active > speaker from source captures VC4 to VC15. If a consumer only wanted to > see the most active speaker it would only select MCC4. >=20 > Regards, Christian >=20 > On 25/09/2013 4:45 AM, Paul Kyzivat wrote: > > On 9/24/13 11:47 AM, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> On 9/24/13 9:31 AM, Christer Holmberg wrote: > >>> Hi, > >>> > >>> Previously, I gave a comment on the role document, indicating that > >>> I would like to have the possibility to indicate things like "2nd > >>> most active speaker", "3rd most active speaker" etc. Etc it is a > >>> dynamic role, which isn't bound the role of a physical person, but > >>> rather to the system. > >>> > >>> However, when thinking more about it, I am not sure whether it > >>> really fits the role concept, or whether it should be something > >>> else. > >>> > >>> Do people have comments on this? > >> > >> I don't even think most active speaker is a role. IMHO a role is > >> something less dynamic (host, scribe, presenter, etc.), whereas "the > >> two or three people who are producing the most sound right now" is a > >> kind of eventing that doesn't result in changes of roles. > >> > >> Just my centigram of silver... > > > > I agree that we don't want roles that change frequently for a given > > capture. So attaching this to a capture when speaking, and removing > > when not is a really bad idea. > > > > But "most active speaker" and "second most active speaker" *could* be > > roles carried by *switched* captures. They would be statically > > assigned - this switched capture always contains the most active speake= r. > > > > I'm undecided whether I like that. It could solve some problems for us. > > > > What do others think? > > > > Thanks, > > Paul > > > >> Peter > >> > >> - -- > >> Peter Saint-Andre > >> https://stpeter.im/ > >> > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > >> Comment: GPGTools - http://gpgtools.org > >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >> > >> iQIcBAEBAgAGBQJSQbQRAAoJEOoGpJErxa2p2gYQAKEmIQhCaekyng/Gj0B5I+4A > >> qCB/eWQulUjqsxPIpqb8qx4ZDhwZEJhIg6qxve+MOWY5gUO8Yby2+wYBGzwQYXl6 > >> /Aas6xox9suGt6UranW7VvJUOlDmnRvkUe7dyww3lBaLPzt+W1DK2VrHlET6GwHe > >> MPr6cJaA/OziXqoMQcsT5hayJ0gJIm5o0Ol7Qho665iHh5hQf8VXuboLbTTjrcTb > >> AgKddjoCudBcDaCsey3hAWCmk8OlYHvHNNSgVCbbK+UGxebadzmDNctic4xoV38y > >> nA9z5+n4fWAWGWJf+mNX7mcwLpM9e720nk9X7o8YhxM7uhBmVkSxJnEaxYQTXc1h > >> RhALsieIxQ5vZ/poJiX66i8RZ/jH94p81iwuBaVftlg+MsVI40tKY4hBtqS/U73H > >> Bq2oK2wKAeoyZClLB39R+9RfzNvNeJoNBST3tvzMMhUWh3iDeJgfirVNaaqrqF7R > >> ucN+cWISz1cFigznKPJvno4UqgpLbAwI8bYalu3sGPMY1p2t8ulEgUiCSQti6DSm > >> TL2vuFDSqKH7ATCYUNMsuOzOpV/Mr/Y47Eu3Ksqi/XPj+IcmjbTPvyZ0kU7j/6vU > >> 66WQhHWlc9fl82Wl6J2WicmIDDCOtZ9YagBwObme09XqKCDSl3JlXB1y+t9zn9EK > >> bkuiL3QvoacUrL+QXIeW > >> =3DFRgG > >> -----END PGP SIGNATURE----- > >> _______________________________________________ > >> 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 rohanse2@cisco.com Mon Sep 30 09:42:26 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDA521F97C7 for ; Mon, 30 Sep 2013 09:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QekvMU3yhv+t for ; Mon, 30 Sep 2013 09:42:21 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6A87B21F995F for ; Mon, 30 Sep 2013 09:42:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17335; q=dns/txt; s=iport; t=1380559340; x=1381768940; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=qAZeuysYHJRB1ThZCEqdT6+hXfx8ESEsuO7fTd1Xh6I=; b=kvhGGg1by0mreVPOH1O0VVZdpHXvBEdHInQyuCjuxNown0AdZgKH0MxG 1/OAnzhMIPXhWfWAQUEbqV1PGFUMFSFkzLwE9ynz/cExmPQwUutV+x4Dh 6nv/z93vUe7xa2ElMUyOkdCiMstzinrBwW5d2uL67Sz8Mmd3PbltTeM4M 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAI+oSVKQ/khR/2dsb2JhbABZgwc4wU+BLhZ0giUBAQEDAQEBATUwBgQGDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBh3wGDL1qBI4TgUUGhBwDlCKDXYYzi0aDJTuBLAEEAhk X-IronPort-AV: E=Sophos;i="4.90,1009,1371081600"; d="scan'208";a="18393636" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-4.cisco.com with ESMTP; 30 Sep 2013 16:42:14 +0000 Received: from [10.47.196.64] ([10.47.196.64]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8UGgCso008055 for ; Mon, 30 Sep 2013 16:42:12 GMT Message-ID: <5249AA02.3020703@cisco.com> Date: Mon, 30 Sep 2013 17:42:42 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <52391AD2.5000701@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> <5244E2A7.8020601@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333E1FB@CRPMBOXPRD07.polycom.com> <5245FBA5.6060809@nteczone.com> In-Reply-To: <5245FBA5.6060809@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 16:42:26 -0000 Hi Mark, Christian, See inline On 27/09/2013 22:41, Christian Groves wrote: > Hello Mark, > > Please see below. > > Regards, Christian > > On 28/09/2013 1:04 AM, Duckworth, Mark wrote: >> Hi Christian, >> >> I agree the MCU provider can choose to provide as much or as little >> information as it wants. And I agree there could be optimizations to >> reduce CLUE message sizes. Given this, maybe it is enough to address >> the concerns about scaling to large conferences? What do others think? [RH] I think so long as the provider isn't *required* to provide a capture corresponding to every participant in the conference then message sizing is much less of an issue, as it allows the MCU to make sensible choices about how much information to pass on. [RH] I do think that if we adopt this approach it'll necessitate switching to a model where new advertisment messages are deltas of the previous, as opposed to complete refreshes (a la RFC 4575's partial/full update mechanism), so that if the MCU does want to send all participant capture information in a particularly large conference it has a mechanism for doing so without being required to send a vast XML document every time anyone leaves or joins. >> About CapScene9, I have more questions. You suggested the MCU could >> do some image processing to ensure captures are the same size, and >> indicate this by using the same virtual area of capture for each of >> the MCCs. I agree, but I was not too concerned about the relative >> sizes of the captures from different endpoints. I am more concerned >> about the spatial relationship between captures from the same endpoint >> in terms of how to order them next to each other for proper >> rendering. The consumer should have enough information to do this if >> the MCU provides all the original spatial information from each >> endpoint in the advertisement, do you agree? > [CNG]Yes I agree. >> >> One downside to this approach is that every change the MCU makes in >> how it assigns contributing VCs to an MCC (e.g. make a switch based on >> current talker) could result in the consumer renderer needing to >> change how it maps decoder output to display locations. I need to >> think more about if this would really be a problem or not. > [CNG] For this switching case I would think that a consumer would use > the MCC spatial co-ordinate. i.e. in capturescene9 below MCC4 would > always present the active speaker from the list of VC using the same > co-ordinates. Or are you talking about switching the positions in a > composed MCC? [RH] My issue with using the spatial coordinates of the MCC is that it requires the MCU to anticipate the rendering desires of the endpoint, as the MCU will need to advertise MCCs with spatial coordinates that allow the endpoint to do what it wants to do. My concern has always been that this may lead to huge numbers of MCCs and capture scene entries if the MCU is trying to anticipate potential layouts by the endpoint. >> In my example (section 3.2 of my draft) I attempted to address this by >> using multiple scenes, where each scene had fewer VCs (these could >> become MCCs) in each CSE, with some spatial information the MCU would >> adhere to when switching. I'm still leaning toward this multiple >> scene idea. I think combining it with the MCC concept will be an >> improvement. > [CNG] I think the multiple scenes is the way to go. [RH] In terms of our definition of 'scene' it makes sense for the originating VCs to be seperate scenes (since in reality they are indeed seperate rooms), but as far as our current syntax goes then there is an issue with the fact that MCCs would want to reference VCs from different scenes. >> >> Still about CapScene9, you wrote "the MCC could change the location of >> the capture areas in virtual space to suggest some sort of layout to a >> consumer. The 3rd option is not to send spatial information." I don't >> understand what you mean, could you expand on this please? > [CNG] The first part of the sentence refers to be capability to order > them next to each other as you mention above. The 3rd option is to only > send spatial information related to the MCC and not the VCs. In that > case the consumer only knows the overall capture area of the MCC not the > spatial area of the components. >> >> Regards, >> Mark >> >>> -----Original Message----- >>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>> Sent: Thursday, September 26, 2013 9:43 PM >>> To: Duckworth, Mark >>> Cc: clue@ietf.org >>> Subject: Re: Example of MCC >>> >>> Hello Mark, >>> >>> Please see my responses below. >>> >>> Regards, Christian >>> >>> On 27/09/2013 3:29 AM, Duckworth, Mark wrote: >>>> Hello Christian, >>>> >>>> Thanks for the example, this is a good basis for discussion. >>>> >>>> One new key concept here is that CapScene2 through CapScene7 include >>> media captures that are not associated with any encoding group. This >>> indicates the consumer cannot ask for these captures directly in a >>> configure >>> message, because there is no way for the consumer to ask for a capture >>> encoding of any of these captures directly. I have considered this idea >>> before, and it does seem useful. This MCC example is taking this >>> approach >>> with the MCU advertising all the other endpoints' captures, to give >>> information about them, but not for directly putting into capture >>> encodings >>> sent from the MCU. >>> [CNG] Yes that's correct. >>>> However, there could be issues in scaling to large conferences. >>>> Here are >>> two points from draft-duckworth-clue-switching-example-01 (originally >>> from >>> draft-hansen-clue-consumer-layout): >>>> 1. The mixer could advertise all the other endpoint's captures, but >>>> as the >>> size of the conference increases the number of captures that must be >>> advertised will quickly become impractical. >>>> 2. If the renderer had all the spatial information about all >>>> possible original >>> source captures it might receive, it would enable correct spatial >>> rendering. >>> But as the number of captures per endpoint and the number of >>> endpoints in >>> a conference rise caching all the data becomes impractical. >>> [CNG] I think the above are just a natural consequence that as the >>> number of >>> endpoints increase so will the amount of information that needs to be >>> signalled. I think the key point is that with the MCC concept the MCU >>> has to >>> choice to provide as much or as little information as it wants. It >>> doesn't have >>> to pass on all the information that it receives in the source >>> captures, it can >>> filter or manipulate the information as it sees fit. >>> >>> With regards to the 2nd point the MCC concept allows the MCU to provide >>> "harmonised" spatial information regarding the MCC which means the a >>> Consumer could use this information rather than source spatial >>> information if >>> conference size becomes a problem. >>>> I'm not sure what the practical limit on conference size would be. >>>> Maybe >>> there are reasonable ways to do this in large conferences. This >>> needs further >>> thought. >>> [CNG] I don't see that CLUE needs to place any limits on the >>> conference size. >>> I think its largely an endpoint decision on the amount of information >>> it wants >>> to provide. I think there are potential optimisation we can do in the >>> coding of >>> CLUE that will minimise the size of messages. For example introducing a >>> "range" concept to CSEs/MCCs/STSs that could allow to specify a group of >>> captures without specifying every one. >>> >>> MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>> Captures:1}{Policy1}{Encodinggroup1} >>> could be signalled as: >>> MCC100(VC4-VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} >>> >>> Likewise a CSE for CaptureScene9 >>> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12) >>> could be signalled as: >>> CSE(MCC4-MCC12) >>> >>> >>>> CapScene8 below is essentially the same idea as the "advertising >>>> multiple >>> scenes" example in draft-duckworth-clue-switching-example-01, section >>> 3.2. >>> CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft. I >>> assume >>> CapScene8 would include spatial information for MCC1, MCC2, and MCC3. >>> And also I suggest CapScene8 could include other CSEs with fewer >>> captures, >>> such as: >>> MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>> Captures:1}{Policy1}{Encodinggroup1} >>> MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>> Captures:1}{Policy1}{Encodinggroup2} >>> MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>> Captures:1}{Policy1}{Encodinggroup1} >>>> CSE9(MCC100,MCC101) >>>> CSE10(MCC102) >>>> These CSEs would be useful for one or two screen consumers. >>> [CNG] Yes multiple Capture Scenes are used so this aspect parallels >>> section >>> 3.2 in your draft. Yes I agree that Capture8 could include CSEs with >>> fewer >>> captures as you suggest. >>> >>>> I have questions about how to use CapScene9 in the example below. >>> Would MCC4 through MCC12 have any spatial information? If so, what >>> would >>> it be? Or does the consumer rely solely on the spatial information >>> of VC4 >>> through VC15, along with some way of knowing which specific VC it is >>> receiving (within an MCC encoding) at any given time? >>> [CNG] Potentially MCC4 through MCC12 could have spatial information. An >>> advertiser could supply the same "virtual" capture area on each MCC >>> (i.e. a MCU may do some image processing to ensure they captures are the >>> same size) that way the consumer knows the MCCs are the same size. >>> Alternatively the MCC could change the location of the capture areas in >>> virtual space to suggest some sort of layout to a consumer. The 3rd >>> option is not to send spatial information. The above would be the >>> switching case. >>> >>> In a composition case the Advertiser could provide a "harmonised" >>> virtual capture area on the MCC and it could provide capture area >>> information on the individual VCs to give their layout in the >>> "harmonised" capture area. >>> >>> >>>> Would CapScene9 also include other CSEs with fewer media captures in >>> them, indicating a consumer could choose fewer media captures and >>> still get >>> a "representation of the whole scene" without receiving all 9 MCCs? >>> [CNG] CapScene9 could include CSEs with fewer captures. It would come >>> down to whether the Advertiser considers MCC4-MCC12 (or a subset of) as >>> representations of the overall scene or just as individual supplementary >>> streams. >>>> Regards, >>>> Mark >>>> >>>>> -----Original Message----- >>>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>>> Sent: Tuesday, September 17, 2013 11:16 PM >>>>> To: Duckworth, Mark; clue@ietf.org >>>>> Subject: Example of MCC >>>>> >>>>> Hello Mark, >>>>> >>>>> At yesterday's interim you asked if I could use the MCC concept >>>>> (draft-groves-clue-multi-content-00) to support the example in your >>>>> draft >>> ( >>>>> draft-duckworth-clue-switching-example-01). I assume that you were >>> talking >>>>> about the scenario in section 2. >>>>> >>>>> I think it is worthwhile to consider the "Endpoint" advertisements >>>>> also. >>>>> From a CLUE perspective how an endpoint chooses to render the >>> received >>>>> encodings is largely irrelevant as it is up to the local policy. >>>>> >>>>> I would assume the source Advertisements would be something like: >>>>> >>>>> Endpoint A - 4 screens, 3 cameras >>>>> Endpoint B - 3 screens, 3 cameras >>>>> Endpoint C - 3 screens, 3 cameras >>>>> Endpoint D - 3 screens, 3 cameras >>>>> >>>>> Endpoints A-D: >>>>> CaptureScene1[Description=Endpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] >>>>> >>>>> Endpoints E-G: >>>>> CaptureScene1[Description=Endpoint y,VC1,CSE(VC1)] >>>>> >>>>> Note: The endpoints would be likely to use the same IDs in their >>> respective >>>>> Advertisements. >>>>> >>>>> Rather than considering what is displayed the MCC concepts >>>>> concentrates >>>>> more on what the MCU/Mixer sends. The mixer doesn't know anything >>>>> about the number of screens an endpoint has. >>>>> >>>>> My assumption from the figures is that if the 3 main screens are >>>>> "site" >>>>> switching that there is one capture encoding/media stream for each. >>>>> The >>>>> MCU switches in the applicable media into the stream based on voice >>> activity >>>>> [policy1]. I assume endpoint A will not see a capture from itself. The >>>>> descriptions are just for information. >>>>> >>>>> Using the MCC concept the MCU would Advertise to endpoint A: >>>>> ----------------------------------------------------------- >>>>> >>>>> CapScene2[Description=Endpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] >>>>> >>>>> CapScene3[Description=Endpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] >>>>> >>>>> CapScene4[Description=Endpoint >>>>> D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] >>>>> >>>>> CapScene5[Description=Endpoint E,VC13,(CSE5(VC13)] >>>>> >>>>> CapScene6[Description=Endpoint F,VC14,(CSE6(VC13)] >>>>> >>>>> CapScene7[Description=Endpoint G,VC15,(CSE7(VC13)] >>>>> >>>>> // The above part effectively is the same as the input advertisements. >>>>> There are no capture encodings associated with them. >>>>> >>>>> CapScene8[Description=Output3streammix, >>>>> MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} >>>>> {Encodinggroup1} >>>>> MCC2(VC5,VC8,VC11,VC13,VC14,VC15) >>>>> {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} >>>>> {Encodinggroup2} >>>>> MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} >>>>> {Encodinggroup3} >>>>> CSE8(MCC1,MCC2,MCC3) >>>>> >>>>> // The above part describes the switched 3 main streams that relate to >>> site >>>>> switching. MaxCaptures:1 indicates that only one capture from the >>>>> MCC is >>>>> sent at a particular time. The default if it wasn't included is 1 >>>>> so it doesn't >>>>> need to be sent but included for clarity. Sync-id:1 indicates that >>>>> the source >>>>> sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15 >>>>> nothing will be sent in the other MCCs. >>>>> >>>>> CapScene9[Description=Output9streams, >>>>> MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} >>>>> >>>>> MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} >>>>> >>>>> MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} >>>>> >>>>> MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} >>>>> >>>>> MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} >>>>> >>>>> MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} >>>>> >>>>> MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} >>>>> >>>>> MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} >>>>> >>>>> MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} >>>>> >>>>> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] >>>>> >>>>> // The above part indicates that there are 9 capture encodings. >>>>> Each of >>> the >>>>> capture encodings may contain any captures from any source site with a >>>>> maximum of one capture at a time. Which capture is present is >>> determined >>>>> by Policy2. >>>>> >>>>> If the MCU wanted to provide a composed capture encoding of the 9 >>>>> captures it could Advertise in addition: >>>>> CapScene10[Description=NineTiles, >>>>> MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>> VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} >>>>> CSE(MCC13) >>>>> // As maxcaptures is 9 it indicates that the capture encoding contains >>>>> information from up to 9 sources at a time. >>>>> >>>>> [CNG] The above arrangement allows a Consumer to understand how the >>>>> captures relate to the source sites. It means a Consumer can choose >>>>> not >>> to >>>>> receive information from a particular source. This is not possible >>>>> according >>> to >>>>> the "one big scene" approach below. >>>>> >>>>> The Advertisement for Endpoint B in your draft would be identical >>>>> to the >>>>> above other than the captures from Endpoint A would be added and the >>>>> captures from Endpoint B would be removed. >>>>> >>>>> I hope this provides some clarification. >>>>> >>>>> Regards, Christian >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Mark.Duckworth@polycom.com Mon Sep 30 10:18:42 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A39021F8417 for ; Mon, 30 Sep 2013 10:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyqhDMcMxX0s for ; Mon, 30 Sep 2013 10:18:38 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6707A21F91F2 for ; Mon, 30 Sep 2013 10:18:38 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([fe80::5efe:10.236.0.154%12]) with mapi; Mon, 30 Sep 2013 10:18:37 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 30 Sep 2013 10:18:35 -0700 Thread-Topic: Ticket #36 removing pixels per second from framework encoding and encoding group Thread-Index: Ac69+tzeqvxcwH10TZmSFJrUEAD1Zg== Message-ID: <49E45C59CA48264997FEBFB29B6BC2D60344FA83@CRPMBOXPRD07.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_49E45C59CA48264997FEBFB29B6BC2D60344FA83CRPMBOXPRD07pol_" MIME-Version: 1.0 Subject: [clue] Ticket #36 removing pixels per second from framework encoding and encoding group X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 17:18:42 -0000 --_000_49E45C59CA48264997FEBFB29B6BC2D60344FA83CRPMBOXPRD07pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ticket #36 - Cleanup enc= oding parameters for pixels/sec (computational complexity) Please comment on these specific changes I am proposing. At the interim meeting, I said I would propose changes to remove some of th= is detail from the framework. We agreed the framework should not itemize o= r give detail on codec specific parameters. Here is what I will change in the framework regarding the pixels per second= in an Encoding Group (section 7.2): Change from: "By grouping multiple individual Encodings together, an Encoding Group desc= ribes additional constraints on bandwidth and other parameters for the grou= p." To: "By grouping multiple individual Encodings together, an Encoding Group desc= ribes additional constraints on bandwidth for the group." Remove list item: "Maximum number of pixels per second for all video encodi= ngs of the group combined." Remove sentence: "Likewise, the sum of the pixels per second of each instan= tiated encoding in the group must not exceed the group value." Remove references to MaxGroupPps in section 11.1.1 and 11.1.2 examples. Re= move explanation about trading off between resolution and framerate among e= ncodings in a group. Keep something about trading off bandwidth according = to maxBandwidth and maxGroupBandwidth parameters. For individual encodings this is the current text in section 7.1: =3D=3D=3D=3D begin current =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An Individual Encoding represents a way to encode a Media Capture to bec= ome a Capture Encoding, to be sent as an encoded media stream from the Prov= ider to the Consumer. An Individual Encoding has a set of parameters chara= cterizing how the media is encoded. Different media types have different parameters, and different encoding = algorithms may have different parameters. An Individual Encoding can be as= signed to at most one Capture Encoding at any given time. The parameters of an Individual Encoding represent the maximum values fo= r certain aspects of the encoding. A particular instantiation into a Captu= re Encoding might use lower values than these maximums. In general, the parameters of an Individual Encoding have been chosen to= represent those negotiable parameters of media codecs of the media type th= at greatly influence computational complexity, while abstracting from detai= ls of particular media codecs used. The parameters have been chosen with t= hose media codecs in mind that have seen wide deployment in the video confe= rencing and Telepresence industry. For video codecs (using H.26x compression technologies), those parameter= s include: * Maximum bitrate; * Maximum picture size in pixels; * Maxmimum number of pixels to be processed per second; and * Clue-protocol internal information. For audio codecs, so far only one parameter has been identified: Maximum bitrate. =3D=3D=3D=3D end current =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I propose keeping the first three paragraphs as is. And change the rest to= something like this: =3D=3D=3D=3D begin proposed=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Individual Encoding parameters are represented in SDP [RFC4566], not in = CLUE messages. For example, for a video encoding using H.26x compression t= echnologies, this can include parameters such as: * Maximum bandwidth; * Maximum picture size in pixels; * Maxmimum number of pixels to be processed per second; The bandwidth parameter is the only one that specifically relates to a CLUE= Advertisement, as it can be further constrained by the maximum group bandw= idth in an Encoding Group. =3D=3D=3D=3D end proposed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards, Mark --_000_49E45C59CA48264997FEBFB29B6BC2D60344FA83CRPMBOXPRD07pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ticket #36 - Cleanup enco= ding parameters for pixels/sec (computational complexity)

 

Please comment = on these specific changes I am proposing.

 

At the interim meeting, I said = I would propose changes to remove some of this detail from the framework.&n= bsp; We agreed the framework should not itemize or give detail on codec spe= cific parameters.

 

<= p class=3DMsoNormal>Here is what I will change in the framework regarding t= he pixels per second in an Encoding Group (section 7.2):

 

Change from:

“By grouping multiple individual Enco= dings together, an Encoding Group describes additional constraints on bandw= idth and other parameters for the group.”

To:

“By grouping multiple = individual Encodings together, an Encoding Group describes additional const= raints on bandwidth for the group.”

 

Remove list item: “Maximu= m number of pixels per second for all video encodings of the group combined= .”

 

Remove sentence: “Likewise, the sum of the pixels per se= cond of each instantiated encoding in the group must not exceed the group v= alue.”

 

Remove references to MaxGroupPps in section 11.1.1 and 11.1.= 2 examples.  Remove explanation about trading off between resolution a= nd framerate among encodings in a group.  Keep something about trading= off bandwidth according to maxBandwidth and maxGroupBandwidth parameters.<= o:p>

 

 

For individual encodings this i= s the current text in section 7.1:

=3D= =3D=3D=3D begin current =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

   An Individual Encoding represent= s a way to encode a Media Capture to become a Capture Encoding, to be sent = as an encoded media stream from the Provider to the Consumer.  An Indi= vidual Encoding has a set of parameters characterizing how the media is enc= oded.

   Different media types= have different parameters, and different encoding algorithms may have diff= erent parameters.  An Individual Encoding can be assigned to at most o= ne Capture Encoding at any given time.

=    The parameters of an Individual Encoding represent the ma= ximum values for certain aspects of the encoding.  A particular instan= tiation into a Capture Encoding might use lower values than these maximums.=

   In general, the parameters= of an Individual Encoding have been chosen to represent those negotiable p= arameters of media codecs of the media type that greatly influence computat= ional complexity, while abstracting from details of particular media codecs= used.  The parameters have been chosen with those media codecs in min= d that have seen wide deployment in the video conferencing and Telepresence= industry. 

   For = video codecs (using H.26x compression technologies), those parameters inclu= de:

·  &nb= sp;      Maximum bi= trate;

·  = ;       Maximu= m picture size in pixels;

·         Maxmimum number of pixels to be processed per second; and=

&m= iddot;    =      Clue-protocol inter= nal information.

   For audio = codecs, so far only one parameter has been identified:

Maximum bitrate.

=3D=3D= =3D=3D end current =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I prop= ose keeping the first three paragraphs as is.  And change the rest to = something like this:

=3D=3D=3D=3D begin = proposed=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   <first three paragraphs unchanged>

   Individual Encoding parameters ar= e represented in SDP [RFC4566], not in CLUE messages.  For example, fo= r a video encoding using H.26x compression technologies, this can include p= arameters such as:

·=          Maximum bandwidth;

·         Maximum picture size in pixels;

·         Maxmimum number of pixels to be processed per s= econd;

The bandwidth parameter is the on= ly one that specifically relates to a CLUE Advertisement, as it can be furt= her constrained by the maximum group bandwidth in an Encoding Group.

=3D=3D=3D=3D end proposed =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 <= /o:p>

Regards,

M= ark

= --_000_49E45C59CA48264997FEBFB29B6BC2D60344FA83CRPMBOXPRD07pol_-- From Christian.Groves@nteczone.com Mon Sep 30 18:59:38 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72721F9926 for ; Mon, 30 Sep 2013 18:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8OO2vUW1lHY for ; Mon, 30 Sep 2013 18:59:37 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97E21F8C0C for ; Mon, 30 Sep 2013 18:59:32 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAPMrSlJ20Y/m/2dsb2JhbAANRAmDP8FJCYFKgxkBAQEEAQEBNRsVBgQGDQQLEQQBAQEJFggHCQMCAQIBFR8JCBMGAgEBiA6pYJMvBI4PBIFFBoQcA5QimQyBVgEEAg Received: from ppp118-209-143-230.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.143.230]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Oct 2013 11:29:15 +0930 Message-ID: <524A2C70.6000106@nteczone.com> Date: Tue, 01 Oct 2013 11:59:12 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <52391AD2.5000701@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333DEDB@CRPMBOXPRD07.polycom.com> <5244E2A7.8020601@nteczone.com> <49E45C59CA48264997FEBFB29B6BC2D60333E1FB@CRPMBOXPRD07.polycom.com> <5245FBA5.6060809@nteczone.com> <5249AA02.3020703@cisco.com> In-Reply-To: <5249AA02.3020703@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Example of MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 01:59:38 -0000 Hello Rob, Please see my comments below. Regards, Christian On 1/10/2013 2:42 AM, Robert Hansen wrote: > Hi Mark, Christian, > > See inline > > On 27/09/2013 22:41, Christian Groves wrote: >> Hello Mark, >> >> Please see below. >> >> Regards, Christian >> >> On 28/09/2013 1:04 AM, Duckworth, Mark wrote: >>> Hi Christian, >>> >>> I agree the MCU provider can choose to provide as much or as little >>> information as it wants. And I agree there could be optimizations to >>> reduce CLUE message sizes. Given this, maybe it is enough to address >>> the concerns about scaling to large conferences? What do others think? > > [RH] I think so long as the provider isn't *required* to provide a > capture corresponding to every participant in the conference then > message sizing is much less of an issue, as it allows the MCU to make > sensible choices about how much information to pass on. [CNG] No intention to require the provider to provide a capture corresponding to every participant. The intention is to have one mechanism to allow both simple and complex scenarios. > > [RH] I do think that if we adopt this approach it'll necessitate > switching to a model where new advertisment messages are deltas of the > previous, as opposed to complete refreshes (a la RFC 4575's > partial/full update mechanism), so that if the MCU does want to send > all participant capture information in a particularly large conference > it has a mechanism for doing so without being required to send a vast > XML document every time anyone leaves or joins. [CNG] What do you see as the message size threshold to take us from a complete refresh approach to a delta approach? Perhaps we should start another thread on this topic? It was mentioned at the virtual interim that we'll go with the complete refresh approach but I think that was partially due to that it hasn't received any real discussion. > >>> About CapScene9, I have more questions. You suggested the MCU could >>> do some image processing to ensure captures are the same size, and >>> indicate this by using the same virtual area of capture for each of >>> the MCCs. I agree, but I was not too concerned about the relative >>> sizes of the captures from different endpoints. I am more concerned >>> about the spatial relationship between captures from the same endpoint >>> in terms of how to order them next to each other for proper >>> rendering. The consumer should have enough information to do this if >>> the MCU provides all the original spatial information from each >>> endpoint in the advertisement, do you agree? >> [CNG]Yes I agree. >>> >>> One downside to this approach is that every change the MCU makes in >>> how it assigns contributing VCs to an MCC (e.g. make a switch based on >>> current talker) could result in the consumer renderer needing to >>> change how it maps decoder output to display locations. I need to >>> think more about if this would really be a problem or not. >> [CNG] For this switching case I would think that a consumer would use >> the MCC spatial co-ordinate. i.e. in capturescene9 below MCC4 would >> always present the active speaker from the list of VC using the same >> co-ordinates. Or are you talking about switching the positions in a >> composed MCC? > > [RH] My issue with using the spatial coordinates of the MCC is that it > requires the MCU to anticipate the rendering desires of the endpoint, > as the MCU will need to advertise MCCs with spatial coordinates that > allow the endpoint to do what it wants to do. My concern has always > been that this may lead to huge numbers of MCCs and capture scene > entries if the MCU is trying to anticipate potential layouts by the > endpoint. [CNG] A consumer can choose to render how it sees fit. The spatial information is a guide. If the MCU advertises a switched MCC showing the most active speaker in the left position and a MCC showing the second most active speaker in the right position there's nothing stopping the consumer from swapping the positions when rendering. I don't think its up to an Advertiser to provide every conceivable spatial layout. > >>> In my example (section 3.2 of my draft) I attempted to address this by >>> using multiple scenes, where each scene had fewer VCs (these could >>> become MCCs) in each CSE, with some spatial information the MCU would >>> adhere to when switching. I'm still leaning toward this multiple >>> scene idea. I think combining it with the MCC concept will be an >>> improvement. >> [CNG] I think the multiple scenes is the way to go. > > [RH] In terms of our definition of 'scene' it makes sense for the > originating VCs to be seperate scenes (since in reality they are > indeed seperate rooms), but as far as our current syntax goes then > there is an issue with the fact that MCCs would want to reference VCs > from different scenes. [CNG] Yes I agree, this is detailed in my draft, sect 3.1.2 "/Note: Section 6.1/[I-D.ietf-clue-framework] indicates that "A Media Capture is associated with exactly one Capture Scene". For MCC this could be further clarified to indicate that "A Media Capture is defined in a capture scene and is given an advertisement unique identity. The identity may be referenced outside the Capture Scene// // that defines it through a multiple content capture (MCC)./" > >>> >>> Still about CapScene9, you wrote "the MCC could change the location of >>> the capture areas in virtual space to suggest some sort of layout to a >>> consumer. The 3rd option is not to send spatial information." I don't >>> understand what you mean, could you expand on this please? >> [CNG] The first part of the sentence refers to be capability to order >> them next to each other as you mention above. The 3rd option is to only >> send spatial information related to the MCC and not the VCs. In that >> case the consumer only knows the overall capture area of the MCC not the >> spatial area of the components. >>> >>> Regards, >>> Mark >>> >>>> -----Original Message----- >>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>> Sent: Thursday, September 26, 2013 9:43 PM >>>> To: Duckworth, Mark >>>> Cc: clue@ietf.org >>>> Subject: Re: Example of MCC >>>> >>>> Hello Mark, >>>> >>>> Please see my responses below. >>>> >>>> Regards, Christian >>>> >>>> On 27/09/2013 3:29 AM, Duckworth, Mark wrote: >>>>> Hello Christian, >>>>> >>>>> Thanks for the example, this is a good basis for discussion. >>>>> >>>>> One new key concept here is that CapScene2 through CapScene7 include >>>> media captures that are not associated with any encoding group. This >>>> indicates the consumer cannot ask for these captures directly in a >>>> configure >>>> message, because there is no way for the consumer to ask for a capture >>>> encoding of any of these captures directly. I have considered this >>>> idea >>>> before, and it does seem useful. This MCC example is taking this >>>> approach >>>> with the MCU advertising all the other endpoints' captures, to give >>>> information about them, but not for directly putting into capture >>>> encodings >>>> sent from the MCU. >>>> [CNG] Yes that's correct. >>>>> However, there could be issues in scaling to large conferences. >>>>> Here are >>>> two points from draft-duckworth-clue-switching-example-01 (originally >>>> from >>>> draft-hansen-clue-consumer-layout): >>>>> 1. The mixer could advertise all the other endpoint's captures, but >>>>> as the >>>> size of the conference increases the number of captures that must be >>>> advertised will quickly become impractical. >>>>> 2. If the renderer had all the spatial information about all >>>>> possible original >>>> source captures it might receive, it would enable correct spatial >>>> rendering. >>>> But as the number of captures per endpoint and the number of >>>> endpoints in >>>> a conference rise caching all the data becomes impractical. >>>> [CNG] I think the above are just a natural consequence that as the >>>> number of >>>> endpoints increase so will the amount of information that needs to be >>>> signalled. I think the key point is that with the MCC concept the MCU >>>> has to >>>> choice to provide as much or as little information as it wants. It >>>> doesn't have >>>> to pass on all the information that it receives in the source >>>> captures, it can >>>> filter or manipulate the information as it sees fit. >>>> >>>> With regards to the 2nd point the MCC concept allows the MCU to >>>> provide >>>> "harmonised" spatial information regarding the MCC which means the a >>>> Consumer could use this information rather than source spatial >>>> information if >>>> conference size becomes a problem. >>>>> I'm not sure what the practical limit on conference size would be. >>>>> Maybe >>>> there are reasonable ways to do this in large conferences. This >>>> needs further >>>> thought. >>>> [CNG] I don't see that CLUE needs to place any limits on the >>>> conference size. >>>> I think its largely an endpoint decision on the amount of information >>>> it wants >>>> to provide. I think there are potential optimisation we can do in the >>>> coding of >>>> CLUE that will minimise the size of messages. For example >>>> introducing a >>>> "range" concept to CSEs/MCCs/STSs that could allow to specify a >>>> group of >>>> captures without specifying every one. >>>> >>>> MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>>> Captures:1}{Policy1}{Encodinggroup1} >>>> could be signalled as: >>>> MCC100(VC4-VC15){MaxCaptures:1}{Policy1}{Encodinggroup1} >>>> >>>> Likewise a CSE for CaptureScene9 >>>> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12) >>>> could be signalled as: >>>> CSE(MCC4-MCC12) >>>> >>>> >>>>> CapScene8 below is essentially the same idea as the "advertising >>>>> multiple >>>> scenes" example in draft-duckworth-clue-switching-example-01, section >>>> 3.2. >>>> CapScene8 is analogous to Capture Scene 1 in Figure 5 of my draft. I >>>> assume >>>> CapScene8 would include spatial information for MCC1, MCC2, and MCC3. >>>> And also I suggest CapScene8 could include other CSEs with fewer >>>> captures, >>>> such as: >>>> MCC100(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>>> Captures:1}{Policy1}{Encodinggroup1} >>>> MCC101(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>>> Captures:1}{Policy1}{Encodinggroup2} >>>> MCC102(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13,VC14,VC15){Max >>>> Captures:1}{Policy1}{Encodinggroup1} >>>>> CSE9(MCC100,MCC101) >>>>> CSE10(MCC102) >>>>> These CSEs would be useful for one or two screen consumers. >>>> [CNG] Yes multiple Capture Scenes are used so this aspect parallels >>>> section >>>> 3.2 in your draft. Yes I agree that Capture8 could include CSEs with >>>> fewer >>>> captures as you suggest. >>>> >>>>> I have questions about how to use CapScene9 in the example below. >>>> Would MCC4 through MCC12 have any spatial information? If so, what >>>> would >>>> it be? Or does the consumer rely solely on the spatial information >>>> of VC4 >>>> through VC15, along with some way of knowing which specific VC it is >>>> receiving (within an MCC encoding) at any given time? >>>> [CNG] Potentially MCC4 through MCC12 could have spatial >>>> information. An >>>> advertiser could supply the same "virtual" capture area on each MCC >>>> (i.e. a MCU may do some image processing to ensure they captures >>>> are the >>>> same size) that way the consumer knows the MCCs are the same size. >>>> Alternatively the MCC could change the location of the capture >>>> areas in >>>> virtual space to suggest some sort of layout to a consumer. The 3rd >>>> option is not to send spatial information. The above would be the >>>> switching case. >>>> >>>> In a composition case the Advertiser could provide a "harmonised" >>>> virtual capture area on the MCC and it could provide capture area >>>> information on the individual VCs to give their layout in the >>>> "harmonised" capture area. >>>> >>>> >>>>> Would CapScene9 also include other CSEs with fewer media captures in >>>> them, indicating a consumer could choose fewer media captures and >>>> still get >>>> a "representation of the whole scene" without receiving all 9 MCCs? >>>> [CNG] CapScene9 could include CSEs with fewer captures. It would come >>>> down to whether the Advertiser considers MCC4-MCC12 (or a subset >>>> of) as >>>> representations of the overall scene or just as individual >>>> supplementary >>>> streams. >>>>> Regards, >>>>> Mark >>>>> >>>>>> -----Original Message----- >>>>>> From: Christian Groves [mailto:Christian.Groves@nteczone.com] >>>>>> Sent: Tuesday, September 17, 2013 11:16 PM >>>>>> To: Duckworth, Mark; clue@ietf.org >>>>>> Subject: Example of MCC >>>>>> >>>>>> Hello Mark, >>>>>> >>>>>> At yesterday's interim you asked if I could use the MCC concept >>>>>> (draft-groves-clue-multi-content-00) to support the example in your >>>>>> draft >>>> ( >>>>>> draft-duckworth-clue-switching-example-01). I assume that you were >>>> talking >>>>>> about the scenario in section 2. >>>>>> >>>>>> I think it is worthwhile to consider the "Endpoint" advertisements >>>>>> also. >>>>>> From a CLUE perspective how an endpoint chooses to render the >>>> received >>>>>> encodings is largely irrelevant as it is up to the local policy. >>>>>> >>>>>> I would assume the source Advertisements would be something like: >>>>>> >>>>>> Endpoint A - 4 screens, 3 cameras >>>>>> Endpoint B - 3 screens, 3 cameras >>>>>> Endpoint C - 3 screens, 3 cameras >>>>>> Endpoint D - 3 screens, 3 cameras >>>>>> >>>>>> Endpoints A-D: >>>>>> CaptureScene1[Description=Endpoint x,VC1,VC2,VC3,CSE(VC1,VC2,VC3)] >>>>>> >>>>>> Endpoints E-G: >>>>>> CaptureScene1[Description=Endpoint y,VC1,CSE(VC1)] >>>>>> >>>>>> Note: The endpoints would be likely to use the same IDs in their >>>> respective >>>>>> Advertisements. >>>>>> >>>>>> Rather than considering what is displayed the MCC concepts >>>>>> concentrates >>>>>> more on what the MCU/Mixer sends. The mixer doesn't know anything >>>>>> about the number of screens an endpoint has. >>>>>> >>>>>> My assumption from the figures is that if the 3 main screens are >>>>>> "site" >>>>>> switching that there is one capture encoding/media stream for each. >>>>>> The >>>>>> MCU switches in the applicable media into the stream based on voice >>>> activity >>>>>> [policy1]. I assume endpoint A will not see a capture from >>>>>> itself. The >>>>>> descriptions are just for information. >>>>>> >>>>>> Using the MCC concept the MCU would Advertise to endpoint A: >>>>>> ----------------------------------------------------------- >>>>>> >>>>>> CapScene2[Description=Endpoint B,VC4,VC5,VC6,(CSE2(VC4,VC5,VC6)] >>>>>> >>>>>> CapScene3[Description=Endpoint C,VC7,VC8,VC9,(CSE3(VC7,VC8,VC9)] >>>>>> >>>>>> CapScene4[Description=Endpoint >>>>>> D,VC10,VC11,VC12,(CSE4(VC10,VC11,VC12)] >>>>>> >>>>>> CapScene5[Description=Endpoint E,VC13,(CSE5(VC13)] >>>>>> >>>>>> CapScene6[Description=Endpoint F,VC14,(CSE6(VC13)] >>>>>> >>>>>> CapScene7[Description=Endpoint G,VC15,(CSE7(VC13)] >>>>>> >>>>>> // The above part effectively is the same as the input >>>>>> advertisements. >>>>>> There are no capture encodings associated with them. >>>>>> >>>>>> CapScene8[Description=Output3streammix, >>>>>> MCC1(VC4,VC7,VC10){Sync-id:1}{MaxCaptures:1}{Policy1} >>>>>> {Encodinggroup1} >>>>>> MCC2(VC5,VC8,VC11,VC13,VC14,VC15) >>>>>> {Sync-id:1}{MaxCaptures:1}{MaxCaptures:1}{Policy1} >>>>>> {Encodinggroup2} >>>>>> MCC3(VC6,VC9,VC12){Sync-id:1}{Policy1} >>>>>> {Encodinggroup3} >>>>>> CSE8(MCC1,MCC2,MCC3) >>>>>> >>>>>> // The above part describes the switched 3 main streams that >>>>>> relate to >>>> site >>>>>> switching. MaxCaptures:1 indicates that only one capture from the >>>>>> MCC is >>>>>> sent at a particular time. The default if it wasn't included is 1 >>>>>> so it doesn't >>>>>> need to be sent but included for clarity. Sync-id:1 indicates that >>>>>> the source >>>>>> sending is synchronised. Therefore when MCC2 contains VC13,VC14,VC15 >>>>>> nothing will be sent in the other MCCs. >>>>>> >>>>>> CapScene9[Description=Output9streams, >>>>>> MCC4(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup4} >>>>>> >>>>>> MCC5(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup5} >>>>>> >>>>>> MCC6(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup6} >>>>>> >>>>>> MCC7(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup7} >>>>>> >>>>>> MCC8(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup8} >>>>>> >>>>>> MCC9(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup9} >>>>>> >>>>>> MCC10(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup10} >>>>>> >>>>>> MCC11(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup11} >>>>>> >>>>>> MCC12(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:1}{Policy2}{Encodinggroup12} >>>>>> >>>>>> CSE(MCC4,MCC5,MCC6,MCC7,MCC8,MCC9,MCC10,MCC11,MCC12}] >>>>>> >>>>>> // The above part indicates that there are 9 capture encodings. >>>>>> Each of >>>> the >>>>>> capture encodings may contain any captures from any source site >>>>>> with a >>>>>> maximum of one capture at a time. Which capture is present is >>>> determined >>>>>> by Policy2. >>>>>> >>>>>> If the MCU wanted to provide a composed capture encoding of the 9 >>>>>> captures it could Advertise in addition: >>>>>> CapScene10[Description=NineTiles, >>>>>> MCC13(VC4,VC5,VC6,VC7,VC8,VC9,VC10,VC11,VC12,VC13, >>>>>> VC14,VC15){MaxCaptures:9}{Policy3}{Encodinggroup13} >>>>>> CSE(MCC13) >>>>>> // As maxcaptures is 9 it indicates that the capture encoding >>>>>> contains >>>>>> information from up to 9 sources at a time. >>>>>> >>>>>> [CNG] The above arrangement allows a Consumer to understand how the >>>>>> captures relate to the source sites. It means a Consumer can choose >>>>>> not >>>> to >>>>>> receive information from a particular source. This is not possible >>>>>> according >>>> to >>>>>> the "one big scene" approach below. >>>>>> >>>>>> The Advertisement for Endpoint B in your draft would be identical >>>>>> to the >>>>>> above other than the captures from Endpoint A would be added and the >>>>>> captures from Endpoint B would be removed. >>>>>> >>>>>> I hope this provides some clarification. >>>>>> >>>>>> Regards, Christian >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Sep 30 19:10:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0347B21F99D5 for ; Mon, 30 Sep 2013 19:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If+B9RtwItho for ; Mon, 30 Sep 2013 19:10:13 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 6960421F88DD for ; Mon, 30 Sep 2013 19:10:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAJQuSlJ20Y/m/2dsb2JhbAANTYM/wVKBSoMZAQEBAwEBAQEvAQUbFQYKAQULCxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBh3wSqWaTLgSPUQcGhBwDrS4 Received: from ppp118-209-143-230.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.143.230]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Oct 2013 11:40:10 +0930 Message-ID: <524A2EFF.9040908@nteczone.com> Date: Tue, 01 Oct 2013 12:10:07 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B1C4AD505@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333DFF1@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4AD717@ESESSMB209.ericsson.se>, <5244D7DC.6080005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4ADDA5@ESESSMB209.ericsson.se>, <49E45C59CA48264997FEBFB29B6BC2D60333E1A4@CRPMBOXPRD07.polycom.com> <7594FB04B1934943A5C02806D1A2204B1C4ADFB9@ESESSMB209.ericsson.se>, <5245FE6A.5080704@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C4AEA35@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "clue@ietf.org" Subject: Re: [clue] MCC with CSE X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 02:10:14 -0000 Hello Christer, Please see below. Regards, Christian On 28/09/2013 9:57 PM, Christer Holmberg wrote: > > Hi, > > > >I had the same reaction as Mark, if the consumer doesn't want to know > >about the sources then the MCU could simply just advertise a VC (main, > >slide) to represent the single stream from each site. > > > >A minimal implementation for switching could just specify > >MCC():MaxCaptures=1,Attribute(Main,slide),Policy=activespeaker. This > >would say the capture is a switched capture showing one capture at a > >time based on who is the active speaker, that is main and slides. > > Correct. > > > >If you did want the whole source information in this case you are doing > >composition and switching so multiple MCCs would be needed. > > > >E.g. CaptureScene1 VC1(Main),VC2(Slides) > >MCC1(VC1,VC2,Maxcaptures=2(i.e. composed) > >CaptureScene2 VC3(Main),VC4(Slides) > >MCC2(VC3,VC4,Maxcaptures=2(i.e. composed) > >CaptureScene3 MCC3(MCC1,MCC2,MaxCaptures=1 (i.e. switched),Policy=active > >speaker),encodinggroup > > I don't necessarily want the source information. But, I may want to > know e.g. which sites are used to compose the MCC content. But, maybe > such "metadata" can be provided using some composed attribute, or > something? > [CNG]"Site" information is related to the "CaptureScene" level. So to a have a "site/scene" level information at the capture level doesn't seem right. To capture the metadata for each "site" in an MCC: CaptureScene1(Description=SiteA,VC1) CaptureScene2(Description=SiteB,VC2) CaptrueScene3(Description=SiteC,VC3) etc. MCC(VC1,VC2,VC3,etc.) Because each of the VCs is in it's own CaptureScene this allows site level metadata to be communicated to the consumer.The MCU may have received wildly different Advertisements from each of those sites. e.g. those advertisements could have 10s of captures. The MCU has decided only to send very basic information to the consumer as to the sources of the MCC. > Also, I assume that an MCC doesn't necessarily have to be generated by > an MCU. An endpoint could also advertise an MCC, e.g. the one in my > example with main and slide. > > Regards, > > Christer > > > > > On 28/09/2013 1:30 AM, Christer Holmberg wrote: > > > > Hi Mark, > > > > Se comments inline. > > > > The currently proposal works when the content of an MCC is one or more > > individual VCs, which the receiver can choose. That works fine when > > the MCU does switching. > > > > But, in my opinion it does not work for composed MCCs, where the > > content of the MCC can be built based on multiple > > > > Take an example: > > > > - in a conference, each site provides a CSE which contains two VCs: > > one with main video, and one with slides/screen sharing. > > > > - the MCU wants to provide, at any given time, one of these CSEs (the > > selection might be based on active speaker, or whatever) is a single > > stream towards an endpoint. So, it advertises an "main-slide CSE from > > the site with the active speaker site" MCC. > > > > Now, I don't want the receiver to receive all the VCs, from the > > different sites, and try to figure out which belong toghether etc. > > And, the more VCs an CSE consist of, the more complicated it gets. > > > > *//* > > > > */[Duckworth, Mark] If the MCU does not want to advertise anything > > about the other endpoint’s VCs, then what is the point of using an MCC > > at all? In this case, the MCU should simply advertise a composed VC./* > > > > *//* > > > > */[Christer] Sure, the MCU could do that. /* > > > > *//* > > > > */However, there are more to sites than the VCs. For example, I may > > want to advertise which sites are used to compose the MCC content. > > (however, CSE may not be the best way to do that)./* > > > > *//* > > > > */Also, perhaps the MCU wants to advertise what type of video (e.g. > > main and slide) the VC is composed of. I guess I could do something > > like MCC(MCC_Main, MCC_Slide), or something like that.../* > > > > *//* > > > > */Regards,/* > > > > *//* > > > > */Christer/* > > > > *//* > > > > Now, having said that, I DO agree that we should try to keep the > > "hiearchy". > > > > So, in this case, maybe we should introduce a Mixed CSE (MCSE) > > concept. The MCU could then offer a "most active site" MCSE, in which > > it lists the MCC. Something like: MCSE1(MCC1{Policy > > SceneWithTheActiveSpeaker}) > > > > Regards, > > > > Christer > > > > ------------------------------------------------------------------------ > > > > *From:*clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of > > Christian Groves [Christian.Groves@nteczone.com] > > *Sent:* Friday, 27 September 2013 3:57 AM > > *To:* clue@ietf.org > > *Subject:* Re: [clue] MCC with CSE > > > > Hello Christer, > > > > I had considered this issue when putting together the proposal and > > decided that a CSE should be in a MCC. The idea behind the MCC was that > > it was a capture. Captures go in CSEs not the other way around. As Mark > > mentioned using CSEs inside MCCs would lead to nesting issues i.e. > > CS,CSE,MCC,CSE. > > > > Also CSEs have a certain semantic that is that all the captures in the > > CSE make up one representation of a scene. It shouldn't be seen (pardon > > the pun) that CSEs is a syntax shorthand. I think there are other > > options for minimising message size. > > > > Regards, Christian > > > > On 27/09/2013 6:13 AM, Christer Holmberg wrote: > > > > > > Hi, > > > > > > It's up to the advertiser to make sure it doesn't advertise things > > > that it can't provide. > > > > > > The MCU may request a specific CSE from an endpoint, and then > > > advertise that as a composed MCC to another endpoint. I don't see why > > > the MCU should have to advertise the VCs associated with that CSE, > > > when it can simply advertise the CSE. > > > > > > Regards, > > > > > > Christer > > > > > > > ------------------------------------------------------------------------ > > > *From:* clue-bounces@ietf.org > > [clue-bounces@ietf.org] on behalf of > > > Duckworth, Mark [Mark.Duckworth@polycom.com] > > > *Sent:* Thursday, 26 September 2013 11:04 PM > > > *To:* CLUE > > > *Subject:* Re: [clue] MCC with CSE > > > > > > I think it would add complication and confusion to allow this. If > > > allowed, it would be just a shorthand for saying “all the media > > > captures in this CSE can be included in this MCC”. But it also opens > > > the door for nested MCCs (MCC includes a CSE that includes other > > > MCCs), which doesn’t make sense to me, so I suggest we just avoid this > > > shorthand. > > > > > > Mark > > > > > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > > > Of *Christer Holmberg > > > *Sent:* Thursday, September 26, 2013 3:24 PM > > > *To:* CLUE > > > *Subject:* [clue] MCC with CSE > > > > > > Hi, > > > > > > There are some examples of CSEs which contain MCCs (e.g. > > > CSE8(MCC1,MCC2,MCC3)), but I guess it would also be possible to > > > advertise MCCs that contain CSEs (e.g MCC(CSE1, CSE2)). > > > > > > An example is when the MCC is composed of a whole capture scene entry. > > > > > > This is related to the discussion we previously had about simultaneous > > > sets, where I said that it should be possible to advertise, and > > > select, an CSE, rather than having to advertise and select each > > > individual capture within. > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Sep 30 19:17:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8762B21F99F4 for ; Mon, 30 Sep 2013 19:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.055 X-Spam-Level: X-Spam-Status: No, score=-0.055 tagged_above=-999 required=5 tests=[AWL=-2.456, BAYES_00=-2.599, GB_SUMOF=5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0eFEWIb15Hb for ; Mon, 30 Sep 2013 19:17:40 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id DBAFD21F9A57 for ; Mon, 30 Sep 2013 19:17:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALsvSlJ20Y/m/2dsb2JhbAANTYM/wVKBSoMZAQEBBAEBAS8BBRsbChELGAkWDwkDAgECARUwEwYCAQGIDqlpkzKOInw6hCIDmS6SMIFQ Received: from ppp118-209-143-230.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.143.230]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Oct 2013 11:47:34 +0930 Message-ID: <524A30A1.3010900@nteczone.com> Date: Tue, 01 Oct 2013 12:17:05 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <49E45C59CA48264997FEBFB29B6BC2D60344FA83@CRPMBOXPRD07.polycom.com> In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60344FA83@CRPMBOXPRD07.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Ticket #36 removing pixels per second from framework encoding and encoding group X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 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, 01 Oct 2013 02:17:40 -0000 Hello Mark, Looks OK to me. I guess you'll also remove the two editor's notes at the bottom of section 7.1? dt. note: the maximum number of pixel per second are currently expressed as H.264maxmbps. Edt. note: it would be desirable to make the computational complexity mechanism codec independent so to allow for expressing that, say, H.264 codecs are less complex than H.265 codecs, and, therefore, the same hardware can process higher pixel rates for H.264 than for H.265. To be discussed in the WG. Christian On 1/10/2013 3:18 AM, Duckworth, Mark wrote: > > Ticket #36 - > Cleanup encoding parameters for pixels/sec (computational complexity) > > Please comment on these specific changes I am proposing. > > At the interim meeting, I said I would propose changes to remove some > of this detail from the framework. We agreed the framework should not > itemize or give detail on codec specific parameters. > > Here is what I will change in the framework regarding the pixels per > second in an Encoding Group (section 7.2): > > Change from: > > “By grouping multiple individual Encodings together, an Encoding Group > describes additional constraints on bandwidth and other parameters for > the group.” > > To: > > “By grouping multiple individual Encodings together, an Encoding Group > describes additional constraints on bandwidth for the group.” > > Remove list item: “Maximum number of pixels per second for all video > encodings of the group combined.” > > Remove sentence: “Likewise, the sum of the pixels per second of each > instantiated encoding in the group must not exceed the group value.” > > Remove references to MaxGroupPps in section 11.1.1 and 11.1.2 > examples. Remove explanation about trading off between resolution and > framerate among encodings in a group. Keep something about trading off > bandwidth according to maxBandwidth and maxGroupBandwidth parameters. > > For individual encodings this is the current text in section 7.1: > > ==== begin current ======================================== > > An Individual Encoding represents a way to encode a Media Capture to > become a Capture Encoding, to be sent as an encoded media stream from > the Provider to the Consumer. An Individual Encoding has a set of > parameters characterizing how the media is encoded. > > Different media types have different parameters, and different > encoding algorithms may have different parameters. An Individual > Encoding can be assigned to at most one Capture Encoding at any given > time. > > The parameters of an Individual Encoding represent the maximum values > for certain aspects of the encoding. A particular instantiation into a > Capture Encoding might use lower values than these maximums. > > In general, the parameters of an Individual Encoding have been chosen > to represent those negotiable parameters of media codecs of the media > type that greatly influence computational complexity, while > abstracting from details of particular media codecs used. The > parameters have been chosen with those media codecs in mind that have > seen wide deployment in the video conferencing and Telepresence industry. > > For video codecs (using H.26x compression technologies), those > parameters include: > > ·Maximum bitrate; > > ·Maximum picture size in pixels; > > ·Maxmimum number of pixels to be processed per second; and > > ·Clue-protocol internal information. > > For audio codecs, so far only one parameter has been identified: > > Maximum bitrate. > > ==== end current ======================================== > > I propose keeping the first three paragraphs as is. And change the > rest to something like this: > > ==== begin proposed======================================== > > > > Individual Encoding parameters are represented in SDP [RFC4566], not > in CLUE messages. For example, for a video encoding using H.26x > compression technologies, this can include parameters such as: > > ·Maximum bandwidth; > > ·Maximum picture size in pixels; > > ·Maxmimum number of pixels to be processed per second; > > The bandwidth parameter is the only one that specifically relates to a > CLUE Advertisement, as it can be further constrained by the maximum > group bandwidth in an Encoding Group. > > ==== end proposed ======================================== > > Regards, > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Mon Sep 30 21:52:40 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC521F9703 for ; Mon, 30 Sep 2013 21:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMWVntSoMj-8 for ; Mon, 30 Sep 2013 21:52:39 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 7D09721F995B for ; Mon, 30 Sep 2013 21:52:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBABdUSlJ20Y/m/2dsb2JhbAANTYM/wVSBS4MZAQEBAwEBAQEvAQUbGwQGBgsLGAkWDwkDAgECARUwEwYCAQGHfBKpZJM4jhOBRYQiA5kukjCBUIFX Received: from ppp118-209-143-230.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.143.230]) by ipmail05.adl6.internode.on.net with ESMTP; 01 Oct 2013 14:22:36 +0930 Message-ID: <524A54E7.9070601@nteczone.com> Date: Tue, 01 Oct 2013 14:51:51 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: clue@ietf.org References: <028101ceb450$632bc7c0$29835740$@gmail.com> In-Reply-To: <028101ceb450$632bc7c0$29835740$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] CLUE SDP signaling and MMUSIC unfied plan - issues raised in the interim X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 04:52:40 -0000 Hello Roni, Please see my comments below. Regards, Christian On 18/09/2013 7:20 PM, Roni Even wrote: > > Hi, > > At the CLUE interim meeting (September 17^th ) this issue was brought > out as part of the RTP mapping presentation. > > MMSUSIC decided to use the “unified” plan for RTCweb. The plan propose > that an m-line will describe a media source or media stream track. In > CLUE terms this is a media capture. > > The data from a media source can be encoded as a single or multiple > media streams (RTP media stream) or CLUE capture encodings. Examples > for the multiple media streams may be a simulcast proposal of > different resolutions streams or a FEC (forward error correction) > stream to protect the media stream. > > The CLUE signaling draft (individual draft) propose that each SDP > m-line represent a capture encoding and uses the SDP label attribute > to map SDP information to CLUE. This does not work with “unified” plan > since the label attribute is an SDP media level attribute. > > http://tools.ietf.org/id/draft-even-mmusic-application-token-01.txt > discuss some of the issues with using an SDP m-line to describe a > media source including support for FEC and simulcast. The simulcast > support refers to > http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02. > > Note that a FEC stream can protect multiple media capture (one FEC > stream protect all three RTP streams from the three cameras) > > I also think that “bundle” is not an issue since it does not care what > an m-line describes. > > Some questions to discuss > > 1.Does CLUE want to support unified or have an SDP m-line describe a > media source or do we have an m-line describe a capture encoding or > media stream (the relations between the m-line can be described SDP > group attribute or in the CLUE protocol) > [CNG] Do you mean "Does CLUE want to support unified AND and have an SDP m-line...."? To use CLUE I don't think we should have to rely on "unified" however we shouldn't preclude the use of CLUE in systems that do. > 2.How do we describe the FEC stream. This is not a media stream and it > is not really a capture encoding. So do we only have it in the SDP and > no representation in CLUE. This will mean that it is not part of an > encoding group so the total bandwidth limit will be based on SDP and > not only on the encoding group. (this will relate also to the > discussion about how do we describe the limits for encoding group > (CLUE or SDP). > > Currently the authors of the RTP mapping draft (Jonathan and I) are > going to update the document assuming that an m-line represent a > capture encoding (not “unified”) and that FEC is only described in SDP. > [CNG] Describing FEC only in SDP seems logical. Its not really metadata regarding the content of the capture. > > Please look at the application token draft and provide feedback > [CNG] I had a look and thought I understood it but then I re-read it and ended up confused. The examples show the use of the a=appID: however there's nothing with a=extmap:1 urn:ietf:params:rtp-hdrext:App-ID ? I take it the use of a=aapID is no use for CLUE unless you use either the rtp hearer extension of SDES? Sect.3 of the draft indicates to use the token from the unified draft. This is specified as "MUST contain at least 32 characters chosen randomly from full set of 79 characters allowed in a token". So rather than a single digit token i.e. a=appID:2, a more realistic use a 32 character token? > > Thank > > Roni Even > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue